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ABSTRACT 


Advances in communications technology and computers have made possible 
tremendous leaps forward in real-time Command and Control (C2). This 
revolution in C2 capability will provide decisionmakers (DMs) in the Joint 
military organization with an unparalleled tactical and strategic picture of the 
battlefield (“Global Awareness”). The ways in which DMs having Global 
Awareness coordinate their information, resources and activities to fulfill the 
organization’s mission is the focus of the Adaptive Architectures for Command 
and Control (A2C2) project. In order to examine these command and control 
issues empirically, the A2C2 project required a multi-player real-time simulation 
environment. A new computer model was needed to abstract "real world" 
problems into a controlled laboratory environment. The result was the Distributed 
Dynamic Decisionmaking (DDD-III) paradigm. The phase one experiment of die 
A2C2 project was designed to validate the DDD-III paradigm, widi emphasis on 
the manipulation of organizational variables. This document reviews the project 
objectives, DDD-III capabilities, experiment one scenarios and scenario 
development issues. The scenario generator users guide and players tutorial, 
developed during phase one, are provided. The intent of this document is to link 
the phase one experiment to the next, more advanced phase of the A2C2 project. 
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I. INTRODUCTION 


A. DISCUSSION 

Rapid advances in communications technology and computers have made possible 
tremendous leaps forward in real-time Command and Control (C2). This revolution in 
C2 capability will soon provide decisionmakers (DMs) in a Joint military organization 
with an unparalleled tactical and strategic picture of the battlefield. Additionally, a 
decisionmaker will have the ability to rapidly access all information available within the 
organization, monitor actions made by other DMs, and call upon a world-wide data base 
to aid in the decision process. This powerful, all-knowing capability has been dubbed the 
name “Global Awareness”. 

The processes by which DMs having Global Awareness coordinate their 
information, resources and activities to fulfill the organization’s mission, (especially in a 
dynamic and imcertain environment,) are adapting in response to the changing 
informational infrastructure. Current research involving adaptive architectures for Joint 
Command and Control (C2) seeks to examine the interactions between mission 
requirements and organizational structure. The Office of Naval Research has 
commissioned a research effort into this far reaching topic ^ the Adaptive Architectures 
for Command and Control (A2C2) project. This project will explore the changes in task 
structure that drive changes to organizational structure in the Joint warfare environment, 
and how the Joint organization should adapt to such changes. 
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In order to examine these command and control issues empirically, the A2C2 
project required a multi-player real-time simulation environment capable of: 

• Focusing on the dynamic/execution phases of the mission 

• Allowing easy mampulation of key structural variables in task and 
organizational dimensions. 

The approach taken combined empirical and analytical efforts to develop a 
model-based program of experimentation with human teams. A first step in this process 
was to abstract "real world" problems in order to bring them into a controlled laboratory 
environment where we could mampulate a large variety of experimental conditions. 

A new paradigm was needed to support such model-based empirical research, 
resulting in the development of the Distributed Dynamic Decisionmaking (DDD-III) 
paradigm. This third generation paradigm is an evolution of an earlier paradigm, the 
DDD-II, which was the backbone of extensive empirical research from 1989 - 1995 
involving "open-ocean" naval team (distributed) decisionmeiking and coordination. 

This thesis will overview the objectives of the A2C2 project and the general 
requirements of the tier-1 experiments conducted 4-16 March 1996 at the Naval 
Postgraduate School. Emphasis will be on the operationalizing of various dimensions of 
task and organizational structure and the new DDD-III paradigm. 
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B. APPROACH 


1. Project requirements 

We will begin by reviewing the A2C2 project goals. Chapter II will cover the 
general requirements of the project, with emphasis on interactive computer simulations - 
what is currently available and what options were considered for phase one. The basic 
framework of the DDD-III will be discussed, as well as the environment contained in this 
new simulation. 

2. Core elements 

Once the basic DDD model is defined, chapter III will move further into the 
paradigm and a description of the core elements. What elements can the scenario 
designer control to investigate an overall hypothesis? Broken down into three general 
areas; task, platform and organization, the chapter will discuss the specific concepts 
behind each variable changed and the measures monitored to view the results. A 
description of the various dimensions of organizational structure contained in the DDD- 
III wdll be reviewed. 

3. Phase I experiment scenario 

Begiiming in chapter IV the focus of the thesis will shift from the generic DDD 
applications to the specifics of the phase one experiment conducted in March 1996. The 
purpose of this experiment - to test interaction between organizational structure and task 
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structure, will be reviewed. The general hypothesis, implementation and abstraction will 
be explained, emphasizing the details of the scenario used. 

4. Simulation Development 

Chapter V will cover development issues that arose during the phase one 
experiment. The DDD-III continued to evolve during the phase one scenario design, 
allowing for abstraction of specific missions and actions in the Joint world. The 
challenges faced in the design of the display interface, the movement of the various assets 
and the representation of threats are outlined here - along with the solutions found. 

5. Future Issues 

Finally, chapter VI will address several scenario and software elements that arose 
during phase one but were determined to be future issues. 

6. Development aides 

Appendix A contains the scenario generator users guide, developed to assist future 
experimenters in the design of scenarios and their abstraction from the real-world to the 
DDD world. This users guide, when coupled with the players tutorial contained in 
Appendix B, represents the link to phase two experiments. 
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II. A2C2 PROJECT REQUIREMENTS FOR THE DDD-III PARADIGM 


A. A2C2 PROJECT DESCRIPTION 

The Adaptive Architectures for Command and Control (A2C2) project is a four 
year research effort commissioned by the Office of Naval Research (ONR) to study 
emerging issues in command and control (C2). The project’s overall goal is to increase 
the level of knowledge regarding decisionmaking in organizations that must operate in an 
environment, or mission context, that is subject to change. A secondary goal is to extend 
12 years of composite naval warfare decisionmaking research into the Joint C2 arena. 

The focus of the A2C2 project is centered on adaptive architecture structures, such as 
authority, communication, resources ownership, etc., and specifically how these 
architectures should be driven by changes in the Joint environment. 

The A2C2 project involves an "industry-university-govemment" initiative, with 
researchers fi'om the Naval Postgraduate School (NPS), the University of Connecticut, 
Alphatech, Inc., George Mason University, and the MITRE Corp. The research program 
is a three-pronged, coordinated effort that involves field, experimental, and theoretical 
components: 

• Interviews with experienced joint officers 

• Participation in exercises and demonstrations (pooling of theoretical and 
analytical techniques to provide models of decisionmaking and adaptation) 
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• A three-tiered series of experiments with officers in joint settings for 
measurement of individual and team performance in dynamic, evolving 
missions and scenarios. The intent is to subject the results from tier-I 
experiments to further scrutiny in tier-II experimentation, and ul timate ly 
to apply them to improve the command and control abilities of actual C2 
operational organizations. 

As part of the charter of the A2C2 project, a tier-I experiment to test hierarchical 
structure was conducted by the research group at the Naval Postgraduate School (NPS) in 
March 1996. This experiment represents phase one of the A2C2 project. 

B. SIMULATIONS 

In order to determine empirically how structural changes effect an organization’s 
command and control process it is necessary to be able to control the many variables that 
describe that orgamzation. There are basically two paths that can be taken to conduct 
controlled experiments. The first path, which involves the use of real-world assets and 
command orgamzations to investigate an experimental h 5 'pothesis, is unrealistic. It is fair 
to say that it would be “difficult” to convince the Department of Defense to “loan” a fully 
operational Joint Task Force to the A2C2 project for the purposes of experimentation. 

The second, more practical, method is to abstract the important elements of the real-world 
command and control problem into a computer model, or simulation. This simulation 
can then be administered to test subjects, representative of a cross-section of the general 
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military officer populace. The performance of the decisionmaking teams in this 
simulation can then be analyzed statistically, and the results extended to the real-world. 

1. Other simulations 

Computer simulations are not a new concept. Many attempts have been made to 
model the warfare environment, some with more success than others. Several excellent 
war gamming simulators exist today, such as RESA, JTLS and MTWS. These are used 
by individual services and Joint commands to train for future conflicts. These models 
allow for high-level, theater emulation of tactics, but in our experiment the tactical 
performance of the team being tested was in itself not important . The unique A2C2 
project requirement - to change task and organizational structure, thereby directly 
influencing team performance, - did not appear to be effectively supported by any of these 
simulations. Each was reviewed by the A2C2 project, not just for use during phase one 
but for future use as well. 

a. Research Evaluation System Analysis (RESA) 

RESA is a high-level Naval war game which is supported by an extensive 
secret data base and tactical outcomes matrix. The ability to move above the individual 
unit and component level to Fleet and theater decisionmaking is supported, although 
RESA is not designed specifically for that task. The data collection abilities of RESA are 
actually quite good, with some \jser definition possible and most measures of 
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effectiveness (MOE) automatically recorded. The scenarios contained in the software can 
be modified fairly easily, which would allow some degree of control over the tasking anH 
asset competition of the team members. However, operationalizing the changes in 
orgamzation (and task) structure would be more by accident than by design - one would 
have to “trick” the computer into chain of command changes. The ease of use and the 
relatively short training period required for test subjects would be an advantage in cycling 
a large number through the simulation in a short period of time. RESA, however, has no 
capability to model amphibious or ground warfare components, making this simulation 
poor for A2C2 needs in modeling Joint operations. Most significantly, any changes maH^ 
to the simulation could not be supported without major revisions in software. 

b. Joint Theater Level Simulation (JTLS) 

JTLS is a high level Joint w ar game, supported by a large computer data 
base of every conceivable tactical combination of weapons, threats and maneuvers. This 
simulation models the theater level decisionmaking organization while simultaneously 
requiring the user to specify such items as individual platform weapons loads. This 
combination of high level decisions and low, low level planning makes JTLS completely 
unwieldy and cumbersome for our purposes. The simulator is excellent in the 
representation of ground forces, weak in the amphibious world and very, very weak in the 
Naval world. As a result of these combined deficiencies is would be extremely difficult 
to a opwafely model the Joint world. (The name of the simulation not withstanding.) 
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Overall, the simulator is not suitable for abstracting the changes in organization structure 
required. The scenarios and command structures cannot be easily changed by the user 
and would require enormous software modifications to provide the required flexibility. 
Additionally, these software changes would have to be made through an administrative 
and maintenance contractor who holds the rights to the software. 

c. MAGTAF Tactical Warfare System (MTWS) 

MTWS is an excellent, high-level. Joint war game supported by an 
extensive data base, tactical matrix, and outstanding theater level command structure. 

The simulation is mainly concerned with the Theater level decisionmaking process. Data 
collection abilities of MTWS are outstanding, with user definition possible and multiple 
MOE’s covered. The scenarios contained in the software can be easily modified, with all 
degrees of tasking and competition supported. The ease of use and short training period 
required for test subjects, coupled with the small number of support personnel would 
make it possible to have a high rate of experiment throughput. If MTWS had been 
available for small scale use at NFS, tier-I experiments for the A2C2 project might have 
been run using that simulator. Tier-II experiments using MTWS are a very real 
possibility. Providing the ability to incorporate players not collocated, MTWS may soon 
be contained in the Global Command and Control System (GCCS) currently coming on¬ 
line in the field. The GCCS, in addition to possibly supporting the MTWS package, 
provides the decision teams with Distributed Collaborative Planning Aids, a tool that will 
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be used by Joint planners in the real-world. It is envisioned that a candidate for A2C2 
tier-III empirical studies will be GCCS with MTWS as a Joint hybrid game. 

2. Distributive Dynamic Decisionmaking (DDD) -III 

After reviewing the simulators currently in use and available it bec am e apparent 
that a user friendly, easily modified, “low level” command and control simulator was 
required. To support this need the Distributed Dynamic Decisionmaking (DDD-III) 
paradigm was developed, based upon the earlier DDD-II paradigm [Ref 1 ], which was the 
backbone of extensive empirical research fi-om 1989 - 1995 involving "open- ocean" 
naval team (distributed) decisionmaking. The DDD-II paradigm, adaquate for its 
designed purpose, allowed for very little manipulation of command stmcture and other 
organizational variables. The DDD-III represents a huge leap forward in one’s ability to 
model the Joint real-world environment, with a wide range of commands and user defined 
parameters available to abstract the complex components and variables associated with a 
Joint battle space. 

DDD-III provides a multi-player, real-time, model-based simulation environment 
to conduct empirical research within a controlled laboratory environment. The design of 
DDD-III focuses on the dynamic/execution phase of the mission and allows for easy 
mampulation of key structural variables both in task and or ganizati onal dimensions. 
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The software has the ability to handle many abstractions of the Joint world, 
including: 

• Geography/distance 

• A wide variety of task types and classes 

• Moveable platforms (with sensors) 

• Weapons (resources) 

• Subplatforms 

• Ability to impose communication constraints 

• Ability to manipulate the information/resource structure 

The DDD-III was developed to abstract the decisionmaking environment faced by 
a Joint military organization. Limited resources must be allocated by human 
decisionmakers (DMs) to prosecute tasks (i.e., activities or "things to do") in a d 5 mamic 
and uncertain environment. Command and control issues are introduced to the simulation 
exercise though changes in organizational, task and information structures. Objective 
(verses subjective) data collection exists at all levels of the simulation and can be tailored 
by the scenario designer to record nearly every possible variation of the team’s 
performance. While not a true tactical model, the DDD-III can be conceptualized as a 
bridge between the real-world Joint (operational) environment and the laboratory. 
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3. Objectives of the DDD-HI 

The overall objective of the DDD-III development was to provide a multi-player, 
real-time environment to support tier-I (controllable, laboratory-based) empirical research 
for the A2C2 project. The DDD-III was designed to specifically fulfill the following 
needs: 

• Create a “realistic” Joint environment within a computer simulation, 
abstracting the various elements of Army, Navy, Air Force and Marine 
warfare, found in the Joint Task Force environment, to an imderstandable 
computer representation. 

• Provide for the easy manipulation of key structural variables to allow 
testing of basic hypotheses dealing with structural change. 

• Avoid the need to build/require a technical domain expertise in test 
subjects, thereby allowing the experiment to be conducted on-site at NPS 
using available officers. 

• Create a simulator that would allow for ease of scenario design/change, 
data collection and data retrieval. 

C. THE DDD-III ENVIRONMENT 

The overriding hypothesis of the A2C2 research is that changes in task structure 
will drive changes to organi 2 ational structure. Based on this, the DDD-III scenario is 
crafted by the experiment designer to uncover key issues in the organization's 
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decisionmaking and/or coordination processes. The DDD-III must therefore have the 
ability to explicitly operationalize many of the relevant organizational dimensions within 
a Joint task force (JTF). There are three essential factors that make the DDD-III ideal for 
the tier-I experiments to be conducted by the A2C2 project. They are: the concept of 
military “Jointness”, the ability to abstract mission level requirements and finally, to 
impose competition for assets on the teams being tested in order to force intra¬ 
organization coordination 

1. Joint warfare framework 

Warfare of the future will be conducted using mobile, flexible military units 
requiring streamlined command structures. It is almost certain that the military of the 
future will be smaller and that all major operations will be Joint in nature. Based on diese 
assumptions, the Joint warfare concept was used to frame the DDD-III paradigm. A Joint 
Task Force (JTF) commander and subordinate component commanders are used as die 
base level model. Each team member, or decisionmaker (DM), is responsible for 
different but overlapping elements in a common battle space. The forces available to the 
DMs are defined not by the individual service, such as Army, Navy, etc., but by the 
mission to perform; i.e. land, sea, air. 
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Mission structure 


The DDD-III scenario requires test subjects to follow a predefined operational 
order (OPORDER), while simultaneously defending one or more "penetration zones" and 
their own assets, against potential land, sea, and air threats. The OPORDER specifies the 
mission, which is represented in the DDD-III as a series of “tasks". Tasks are defined as 
abstracted activities (things to do) and can range firom taking a beach, clearing a 
minefield, or identifying and (if necessary) prosecuting a hostile contact. The scenario 
designer cati create a template of tasks, with defined attributes, threat capabilities and 
movements. Each task template can then be linked together by time, space and/or 
precedence to provide a theater level mission for the organization to accomplish. 

3. Force competition 

Competition over assets is a major issue in the real-world Joint environment. 

This competition is used to “fiarce” coordination among the DMs - they must set 
priorities, adjusting them dynamically to allocate limited organic and non-organic 
resources in such a manner as to achieve the overall mission objective. How tpamc 
coordinate their efforts, under various organizational structures is the focus of this 
experiment. The competition for assets is effected through manipulation of the t^^sk 
structure, task assignment and responsibility, the command structure and communications 
structure of the decisionmaking team, etc. The DDD-III allows the scenario designer to 
give each DM responsibility for a specific mission area (set of tasks), as defined by 
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OPORDER. The DMs must take action to maneuver their assets/platforms so that tasks 
are brought within sensor or weapons range. As the scenario unfolds, a DM who is 
prosecuting tasks with his own platform(s) might require additional assets from other 
units within the JTF. Thus, the team must coordinate the allocation of assets and 
activities, both for information gathering and task prosecution. Limiting or constraining 
the assets available to the organization will cause DMs to compete for assets in order to 
accomplish their local objectives. This is especially pertinent if the scenario has been 
designed wherein several DMs require a resource simultaneously. These scenario design 
abilities make the DDD-III a powerful empirical instrument. 
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III. DDD-III CORE ELEMENTS 


The DDD-III software gives the user the ability to modify dimensions of task and 
organizational structure in order to test a specific hypothesis. These dimensions are 
considered to be the core elements of the paradigm. We manipulate these dimensions to 
study their interactions, and to present to an organization those task conditions that we 
believe will elicit the desired changes in organizational structure and response. The 
dimensions that can be manipulated are: 

• Task (threat/mission/enemy forces) 

• Platforms (own forces) 

• Organization (command and control) 

A. TASK AND TASK STRUCTURE 

DDD-III represents all missions, opposing forces and threats as “tasks”. During 
the play out of an experimental run, tasks appear, move/maneuver, and disappear 
according to the designer’s scripted scenario. The designer has the ability to define 
veirious dimensions of task structure in order to closely align the DDD-III scenario with 
the overall mission (OPORDER) of the JTF. The characteristics of each task; its class, 
attributes, and resources required, are tailored to specify the threat (such as a fighter, 
minefield, etc.), and to impose situations that will create intra-team coordination (for the 
assets necessary) for task prosecution. 


17 



1. Task type and class 

Tasks are objects, categorized as one of three types: air, surface, or ground. 
Within each type, tasks are further divided into unique classes according to scenario 
requirements. This allows the experiment designer to create, within a given task t 3 q 5 e a 
variety of classes. Examples of groimd type task classes are: minefield clearance, 
armored columns, taking a ground area, surface-to-surface/SCUD missile sites, and even 
"false" tasks. The only real limit to the representative classes is the designer’s 
imagination - the DDD provides a great amount of flexibility. Each class of task/activity 
can be assigned an initial priority, which DM has responsibility, and who has the 
authority (or ability) to prosecute the task(s). 

2. Task attributes 

Associated with each task is a set of (numerical) attributes, written as a vector (A 
= [ai, 32,..., an]) that defines the various characteristics of the task quantitatively. These 
attributes are used to specify such elements as speed, weapons potential, evasive ability, 
IFF status, etc. The number of attributes and their definition depend only on the specific 
needs of the problem being studied. (The first two attributes of any task are in fact fixed 
in definition: Value and Attack time) The true attribute vector for each task within a 
given class is dravra from a normal distribution with a specified mean and standard 
deviation. The DDD-III software provides the designer the option to tailor/override the 
individual values of attributes on a task-by-task basis. 
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Sensors on board the various platforms obtain measurements of task attributes, 
provided the tasks are within their sensor range. The DDD-III has the capability to apply 
a level of “noise” and “bias” to these attribute measurements, providing the ability to 
obscure the true values from the DMs. If the attributes are needed to identify task class 
(e.g., to discriminate a hostile from a neutral, or to identify the class of an incoming patrol 
boat), this obscuring of the measurements may result in mis-identifications, a situation 
that is very possible in the real-world. The means and standard deviations of the sensor 
noises and values of the (circular) sensor ranges can be functions of both task and 
platform class. 


3. Task attributes-to-resource mapping 

The attribute vector gives the DMs requisite information regarding a task's 
characteristics. Once a specific task has been identified or classified, the DM must 
determine the assets required to prosecute it. Associated with each task is a resource 
vector (R = [ri, r2,..., rm]) that defines the resources required for a successful 
prosecution. The designer-defined elements of R can be viewed as generic weapons 
requirements, such as grovuid suppression, mine clearing, anti-air capability, etc., 
depending on the abstraction level of the simulation. Default values for the ri are 
generated within the DDD-III via a designer-defined mapping function f(A, ID). This 
function generates resource reqxiirements from the attributes of file task and its class. The 
DDD-III software also allows the scenario designer to override these values and give a 
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specific resource requirement to any individual task. In the play of the game, subjects are 
automatically given the results of the attnbute-to-resource mapping based on their current 
estimates of A and class ID. This process mimics a staff function recommendation or a 
decision support system. Imprecise knowledge of a task's attribute values and/or a mis- 
identiflcation of class ID will therefore result in incorrect estimates of required resources 
by the DM. 

Attributes and resources are the DDD's lowest-tier constructs for representing 
information/data and weapons systems. We believe that these are valid constructs for 
hierarchical aggregation of activities and assets. This set of constructs precludes the 
experimenter from having to build scenarios from the "bottom-up" to study problems at a 
large force/component level. By treating task attributes and task resources as two 
separate vectors, the DDD-III can be used to study pure (distributed) information 
processing problems, pure (distributed) resource allocation problems, or hybrid cases. 

For example: in a pure resource allocation context, the attributes can be associated one- 
to-one with the resources (ri = ai), with the "measurements" of the ai being made noise- 
free. Our first experiment with the DDD-III used just such a construct. 

4. Task precedence/prerequisites 

A crucial element in scenario design is the ability to assign prerequisites (or 
corequisites) to task accomplishment. This is an important dimension of task structure, 
as it defines correlations and coordination requirements among the individual activities 
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that combine to comprise the mission as a whole. The earlier DDD-II considered each 
task as an independent threat (a "mosquito"), with no consideration given to tasks not 
considered threats or potential threats . The precedence structure implemented in the 
DDD-III allows for task fan-outs and fan-ins. With respect to task fan-outs, the lack of, 
or delay in, accomplishment of a single task can inhibit action on many tasks. For 
example: taking a high ground can be a prerequisite for follow-on introduction of forces. 
With respect to fan-ins, a number of diverse activities may require completion prior to 
mounting a final attack, such as on an airfield (which may be one of the mission 
objectives). 

A "real" task environment does not usually inhibit a DM from making a decision 
or taking an action. In such cases, if actions are completed out of sequence and deviate 
from the initial plein, the consequences may be severe. In our empirical research we need 
the ability to control task structure to a sufficient degree as to prevent teams from creating 
totally arbitrary paths to achieve a final objective. The specification of a prerequisite 
mission/task structure (e.g., clearing minefields before landing on a beach), along with 
the DDD-III's forcing adherence to this structure, provides the appropriate degree of task 
control. 


5. Task parallel processing 

Parallel processing of a task by several DMs is now supported in DDD-III. This 
is a key element in scenario design when assets owned by different organizational units 
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are to be coordinated in time/space for a simultaneous attack. An assault on a hill by a 
Marine unit that is simultaneously supported by CAS, artillery, and Naval gunfire is an 
example of such a multi-resource activity. The DDD-III "scores" the effectiveness of the 
attack as a function of the sychronicity (and correctness) of the allocated assets. 

6. Task spawning 

Missions in the real-world often develop secondary mission objectives during 
prosecution. In DDD-II, task arrivals and disappearances were solely time-driven. No 
consideration was given to event-driven task arrivals. In this environment it is difficult to 
script enemy actions in response to the actions of the subject team. To compensate for 
this short coming, DDD-III was heavily modified to include enemy counterattacks, 
medical evacuations, and other tasks that would be "spawned" by a specific action. (Such 
as a beach landing). The DDD-III implements an extended task structure by allowing a 
primary task to spawn secondary tasks either upon attack of the p rimar y task^ or upon 
disappearance of the primary task. Spawning allows the scenario designer to provide 
dilemmas and conflicts for the organization's decisionmakers. This feature also prevents 
a rote scenario, with the team being led down a single path, solely for the ^akf* of the 
hypothesis under test. For example, the failure to identify and prosecute an enemy 
submarine by a specified time would result in a cruise missile attack upon the CVBG, 
thereby creating a new defensive requirement for the team. 
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7. 


Task removal 


Often the existence of a specific mission is linked to another mission being 
pursued, whether by own forces or another DM. For example, the complete destruction 
of an artillery company by tactical aircraft would negate the requirement for Naval 
Surface Fire Support (NSFS) to suppress this position in the future. In DDD-III, tasks can 
be linked so as to allow for this possibility. The DDD-III implements a task removal 
structure by allowing a primary task to “cancel” a number of secondary tasks upon the 
destruction of the primary task. Task removal allows the scenario designer to further 
increase the richness of the simulation, providing the DMs with a real-world, responsive 
mission structure as the team progresses through the scenario. 


B. PLATFORMS AND PLATFORM STRUCTURE 

A “platform”, or asset, is a basic element of the DDD paradigm that carries 
sensors and resources, modeling the teams friendly order of battle elements. Examples of 
platforms are ships, helicopters, groimd units, bases, etc. A platform may also carry 
subplatforms. For example, a carrier can contain helicopters and various fixed-wing 
aircraft, and the helicopters can carry sonobuoys, etc. With this nesting ability a 
platform/asset structure can be tailored to any level of detail. An amphibious landing, for 
instance, can be modeled by a platform-subplatform structure using sea-going platforms 
that carry ground units for launch at a shoreline. These groiuid units may then have sub¬ 
units of their own. 
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The team identifies and prosecutes tasks by allocating/scheduling its platfo rms , 
ideally to make best use of their generic sensors and resources. A platform can be 
controlled (i.e., geographically repositioned, commanded to attack, etc.), only by the 
current platform owner. Assets have sensor and weapons' ranges, which generally 
depend on task type and platform class. A new feature in the DDD-III is that each 
platform now has a "be-attacked" range, within which specified task classes can inflict 
damage to it. The values for all ranges can be manipulated via the paradigm depending 
on the experimental requirements. 

1. Platform type/class definition 

In a manner similar to tasks, platforms are categorized first by type: air, sea or 
ground, and then by class. The nvunber of platform classes and their individual 
characteristics depend on the requirements of the experiment. Nearly any military 
platform can be represented in an abstracted manner, limited again only by the designers 
imagination. All platforms of a given class will have the same parametric features with 
respect to sensors, weapons, maximal velocity and available subplatforms. The only 
difference among platforms within a given class is their initial owner and location. 

2. Subplatforms 

Subplatforms are actually platforms located on board another, parent, platform. 
These subplatforms provide the DDD-III with a more accurate way to model real-world 
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assets. The “nesting” of subplatforms allows for an additional element in the hierarchical 
asset structure. A subplatform does not become an independent platform until it is 
"launched" from the parent platform. The DM who owns the parent may laimch 
subplatforms that will become available after a specified launch time delay. The DM is 
limited to those subplatforms available on the parent platform, and may only laxmch one 
subplatform class at a time from each platform. Ownership of the subplatform "child" 
can be specified independently. For example, VF assets onboard a Carrier (which is 
owned by the CVBG commander), could be owned by the JFACC when they are 
launched. 

A subplatform is only effective (available for use) for a limited time period. 
Subplatforms are either returnable to their parent (such as helicopters), or non-returnable 
(such as sonobuoys, missiles, etc.). Once returned, a subplatform is not available again 
until a recycle time has elapsed. Subplatforms can also be designated as reusable or non- 
reusable. An asset that is non-reusable can only be used to attack once, (such as an 
artillery round) whereas a reusable subplatform can attack multiple times, within its 
availability window. All parameters relative to subplatform structure and availability are 
designer specified in the DDD-III. 

3. Platform sensors 

Each platform has three types of generic sensors to obtain information on air, 
surface, and ground type tasks. These sensors have specified effectiveness ranges. 
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modeled as circular regions, for task detection, measurement, and 
identification/classification which depend on platform class. However, the DDD-III 
allows the designer to fine-tune these ranges according to individual task classes. Thus, it 
is possible to implement an engineer platoon that detects mines at a further range than a 
tank column would. For a platform to "see" a task, it must be within the platform's 
detection zone; to obtain a measurement of task attributes, the task must be within the 
measurement zone; to obtain task class identification, the task must be wi thin the 
classification zone. As noted earlier, measurements of task attributes may be 
"contaminated" by noise. 

4. Platform resources 

Platforms also contain weapons (or general resource capabilities) for processing 
tasks. The resources on an individual platform (or subplatform) are defined by a 
generalized resource vector, or vector of generalized combat capabilities, R = [ri, rz,..., 
rm], where the elements ri are the same as those associated with task processing 
requirements. A platform of a given class can be used to attack any task, but the range of 
the platform s weapons is a function of task type (or class). In order to engage a task a 
DM must move one or more selected (sub)platforms within range of the task for 
(identification and) attack. Once an attack starts the platform(s) are tied-up for a length 
of time equal to the task's processing time required, az. 
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The resoxirces on the platforms assigned to attack a task must meet or exceed 
those required by the task for the attack to be rated as successful. If the summation of 
allocated resources, on an element-by-element basis, is less tiian the required amotmt, the 
attack will achieve partial success at best. By giving a specific task a value of R the 
DDD-III establishes what (mix of) assets with their corresponding Rs suffice to correctly 
process that task. In this vein, platforms can also be made job-specific. For example, 
mine-clearing helos could have values for, say, rs corresponding to those required for 
mine clearing tasks, but other assets would have lower values of rs, or zero. 

The expression for determining the accuracy of the attack on task j, P(j), can be 
user-modified. After each attack the DDD-III gives a "gain" to the team of V(j)*P(j) and 
a "loss" to the team of V(j)*[l - P(j)], where V(j) = ai = task value. As noted earlier, the 
resources required for task processing are a fiinction of task attributes. The DDD 
provides each DM with an estimate of resources required, using his/her ciarent estimate 
of task attributes and class ID. Thus, accurate task information processing is a precursor 
to correct resource allocation. For example, attacking a task defined as a non-threat will 
always give P(j) = 0.0. 

There is no attrition in the current implementation of the DDD. A poorly done 
attack, an enemy penetration of a defense zone, etc., result only in point loss, and not in a 
loss of assets or asset capability. This was done so that the resources available are not a 
(rmcontrollable) function of the team's sample path through the scenario. This is critical 
to controlled experimentation since the task/mission structure is generally predicated on 
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asset availability. If task structure is to be an independent variable, the total assets 
available should remain constant, or else the team should be allowed to restructure the 
mission. 

C. ORGANIZATIONAL AND ORGANIZATIONAL STRUCTURES 

Orgamzational dimensions refer to the ways in which a multi-person organization 
isstmctured. These dimensions include authority, resource, information and 
communication structure. The structuring of a large organization must mflintain a general 
congruence with the task structure to assure that DMs assigned to subtasks have the 
resources and information required (or can obtain them via a request chain), can 
communicate with other DMs with whom they need to coordinate, and that the "chain of 
command" that is established facilitates successful mission completion. Organizational 
design is a multi-dimensional problem, where one dimension cannot be changed without 
considering concomitant changes in other (supporting) dimensions. The dimensions 
supported in the DDD-III are described below. 

1. Command/authority structure 

Military organizations adopt a command hierarchy to structure the overall 
decisionmaking process. The DDD-III allows for tailoring a “chain of command”, 
provided that each DM in the organization has no more than one "boss". We use a 
general acyclic tree structure to code the command hierarchy by giv ing to each DMj a 
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single integer c(j) < j that defines to whom DMj reports. Command structures ranging 
fi-om totally disconnected [c(j) = j], to totally flat [c(j) = 0], to totally serial [c(j) = j-1] can 
be treated in this consthict. For example, in our experiment wherein two units reported 
directly to the C JTF (DM0), and two other units reported to a common mid-level 
fimctional commander (DM1), we had C = [0,0,0,0,1,1]. 

This generalized authority or command structure is operationalized via task 
assignment and platform/asset assignment capability. As only those DMs assigned to a 
task are 2 illowed to prosecute it, a leader can control dynamically the coordinated actions 
within his (sub)team, and reassign platforms according to mission need. 

a. Task assignment 

In the DDD-III a DM can (re)assign or co-assign a specific task to any 
subordinates DM in his/her sub-organization (subtree). Assignments cannot be made 
upward nor laterally. Assignments are constrained in that: i) a task cannot be taken on 
unilaterally, i.e., the task must have already been assigned to someone in the subtree, and 
ii) the task cannot be given away unilaterally, i.e., assigned away from all DMs. 

b. Platform assignment 

The DDD-III operationalizes a DM's authority over the assets in his/her 
sub-organization in two ways. He can advise a subordinate DM to transfer his asset(s) to 
another DM, or he can independently and unilaterally force a transfer action. If an asset is 
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owned by someone outside of his sub-organization, then all that a DM can do is to 
request use of that asset (from the owner or via the chain of command). 

2. Resource access structure 

This defines both platform ownership and the "mles" by which platforms can be 
requested, transferred, and accessed. At any given time each platform is controlled by the 
DM who owns it. If a platform is defined as transferrable, it can be transferred during the 
simulation from one DM to another, either by the owner or by any of the owner's 
superiors acting through the chain of command. Other platforms can be defined as non- 
transferable, e.g., the amphibious ships (which belonged to the ARG), and the aircraft 
earner (which belonged to the C VBG) in experiment 1. The transfer of an asset from one 
DM to another requires a finite (user-specified) time delay, during which period the asset 
is "locked up," or inhibited from accepting other commands. 

A subplatform nesting structure, wherein the "owner" of a platform is not 
necessarily the owner of its subplatforms, is supported within the DDD-III. Some 
subplatforms can also be assigned permanently to the parent asset irrespective of 
ownership, such as a ship's self-defense assets. 

3. Information structure 

The information (access) structure describes how data collected by platform 
sensors is distributed to the various DMs in the organization. The information structure is 
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operationalized in the DDD-III by defining an information network. Each DM can be 
assigned a level of "tie in" to the information network depending on task type. Each task 
class can be tailored to be viewed differently by each platform class, allowing for a truly 
robust and diverse information architecture. 

For example, a leader (who is responsible for global coordination) can be 
provided with global information, while other DMs can be given more detailed local 
information depending on their local decisionmaking responsibilities. A centralized, 
partially centralized or decentralized information structure can be created by setting the 
different network "tie in" levels by task/platform class for different DMs. In the first 
experiment a common operation picture, or true Global Battle Space Awareness, was 
used. Each DM was able to see in real-time the location of all contacts detected in the 
task force operations area. However, detailed attribute data needed for resource 
allocation and/or classification was sometimes only provided to the local DM assigned to 
that task. 


4. Communications structure 

The communication structure specifies who can send messages to whom, and also 
includes parametric data such as receipt delays, equipment delay and "bandwidth". By 
preventing commimications between certain units and forcing communications up and 
down a specific chain of command we are able to observe the impact of different 
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communications structures not just in isolation, but more interestingly in its relationship 
(interaction) with other structural dimensions. 

In running the DDD software we generally inhibit verbal exchanges among DMs 
in order to ease subsequent analysis of the communications data. Thus, computer- 
mediated commumcations is the only way by which DMs can share local information 
about task attributes and ID, request assets, and coordinate actions. The communication 
among DMs is effected through the graphics user interface via a set of preformatted 
commands: 

• Request information: ask a DM to send his local information about a task. 

• Transfer information: transfer one's local information about a task to 
another DM. 

• Request platform: ask a DM to transfer the ownership of a platform to 
another DM. 

• Transfer platform: inform another DM that a platform is being 
transferred to him (or that an earlier request is being denied). 

• Coordinate action: several choices are available in this command and 
can be easily changed to accommodate specifics of the simulation: 

- Ask another DM to either handle, support, or ignore a tas k 

- Tell other DMs of one's intent to handle, support, or ignore a 
certain task. 

Copies of all messages sent by a DM (except for information requests/transfers) 
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are automatically sent to that DM's superior in the chain of command. This keeps the 
higher-level DM apprised of the needs/activities of his subordinates, and is an attempt to 
capture overheard (open) message flow on a DM command net. 

To represent communication and data processing delays, the DDD places a time 
delay on a message transfer. To model a limitation on channel capacity (or channel 
access), the number of communications (N) in a fixed time window (T) can be specified. 

D. DATA COLLECTION 

The first three core elements of the DDD-III were dimensions to be manipulated 
to pursue the experimental hypothesis. The last element and possibly the most important 
is that of data collection. As stated earlier, one of the critical requirements for our 
simulation paradigm was useful data collection and retrieval. Data collection can be 
broken into two subject areas - the data to be recorded, or measures; and the method by 
which the computer system records this data. 

1. Measures 

The A2C2 experimental scenario designer needs the ability to specify exactly 
what measures would be recorded and in what format these measures would be presented. 
The measures for the tier-I experiments can be broken down into two major groups; 
performance and process. 
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a. Performance 

Measures within the performance category represented the overall scores 
of the decisionmaking team in regards to mission accomplishment and team strength. 
The emphasis here was in accomplishing the task, not in how it was done. These 
elements included team strength and the time it took for the accomplishment of tasks or 
series of tasks. 


b. Process 

Measures within the process category recorded the mechanisms by which 
the team accomplished the missions. This set of measures was critical in analyzing the 
data in regard to the overall experimental hypothesis. These measures can be further 
broken down into two broad areas: 

• Communications - A critical measure of the tier-I experiment was 
the interaction between the lower level co mmand ers and the 
command hierarchy. This set of measures indicted 
communications pathways, time of replies and method of 
requesting assistance. 

• Decisionmaking - There were several measures that indicated the 
teams ability to solve problems, such as competition of assets, and 
how well the team was working together. One example of this type 
of measure was the competition score. It was expected that this 
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measure would be an indicator of the degree to which the 
intermediate level of hierarchy contributed to resolving, or 
reducing competition [Ref: 3]. 

2. Output files 

The ability of the DDD-III to provide rapid data retrieval capability was essential 
to our experiment. The software was designed to present data in two separate files; the 
Log file and the Dependent variable file (dep file). 

a. Log file 

The log file is a record of all actions that occurred within the scenario. 
The file is time-tagged and can be used to replay the entire scenario. This feature is of 
tremendous benefit to the experimental designer, who, at a later time, can designate 
additional measures and re-run the scenario to recollect the new measures. 

b. Dep file 

The Dep file is defined by the experimental designer prior to the scenario 
run. The content of the Dep file can be a direct report of measures or an aggregation. 
Available immediately following a scenario run, the Dep file provides the ability to 
perform analysis on-site. 
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IV. DDD-III EXPERIMENT PHASE I SCENARIO 
DESCRIPTION AND REQUIREMENTS 


The DDD-III software provides a mechanism to empirically investigate proposed 
Command and Control theories in a laboratory environment. For the application to the A2C2 
project, the general elements of organization, assets and threats discussed in the first three 
chapters were used to abstract a specific Joint warfare simulation. In this chapter the specifics of 
the phase one A2C2 experiment will be covered. 


A. EXPERIMENT ONE HYPOTHESIS 

The initial A2C2 experiment was designed to investigate the general hjqjothesis that 
there is an interaction between task structure and organization structure. As stated earlier, the 
context for this experiment was that of a Joint task force, involving or not involving the use of 
common functional commanders. For our purposes then the hypothesis can be summarized 
more effectively zis follows: “An organization with a co m mon functional commander is better 
for certain tasks than an organization without one.” The goal of this phase one experiment was 
to determine a feasible method for testing this hypothesis using the DDD-III, to implement the 
method chosen, and to obtain results for later analysis. 

The situations in which common functional commanders were expected to add value 
formed the basis for the two specific hypotheses tested in this experiment: 
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• An organization with a common functional commander is better for tasks that 
require coordination between units in this functional area for the use of assets 
owned by one of them. 

• An organization without a common flmctional commander is better for tasks that 
require coordinated use between units in this functional area of assets not owned 
by any of them. 

The specific variables mampulated during the phase one experiment revolved around 
levels of competition that can were created by limiting assets. Further discussion of these 
manipulations is addressed by Berigan [Ref 4 and 5]. 

B. IMPLEMENTATION 

The experiment was conducted using a network of SUN SPARC™ workstations located 
in the Naval Postgraduate School - Systems Technology Laboratory (STL). The players were 
physically in the same room, although dividers were placed between them to limit any scenario 
knowledge gained by observing the other team members. Talking was restricted during the 
simulation runs, with commumcations among players restricted to the preformatted computer 
messages built into the DDD-IIL 

C. SCENARIO DESCRIPTION 

!• Oeographic/geopolitical 

The scenario chosen was representative of a “typical” future requirement for US forces. 
Orange, a North African nation friendly to the United States, has been attacked by Green, whose 
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forces have taken control of Orange’s port of Eastport. Upon direction from the National 
Command Authority a Joint Task Force (JTF) has been organized by the theater commander in 
chief, the Commander in Chief, Mediterranean Command (CINCMED), in order to capture the 
port and a nearby airfield to allow for the introduction of follow-on forces. The Commander, 
JTF (CJTF) has at his disposal an aircraft carrier battle group (CVBG) and an amphibious ready 
group (ARG) that transports two Marine Expeditionary Units (Special Operations Capable) 
(MEU(SOC)s). 


2. Mission and Execution 

Green forces are located at the port, the airfield, and at other locations in the amphibious 
objective area. About 5 miles south of the port, there are two suitable landing beaches with a 
road leading from the northernmost beach (designated "Red Beach") to the port, and another 
leading from the southernmost beach (designated "Blue Beach") to the airfield. 

The forces from MEUl and MEU2 will land at Red and Blue Beaches, and proceed along the 
roads to capture and secure the port and airfield, respectively. They will use their own assets and 
request the CJTF’s assets as necessary to clear mines at the beaches, conduct MEDEVACs, 
defeat counterattacking armored units, clear mines along the roads, suppress Green artillery, 
destroy Green FROG launchers, and capture the port and airfield. 

The maritime units (CVBG and ARG) support the amphibious operation with CAS, 
NSFS, mine countermeasures, and air defense assets, while defending themselves against air. 




surface, and subsurface threats. They will use their own assets and request the CJTF’s assets to 
destroy Green submarines, fixed-wing aircraft, helicopters, patrol boats, and Silkworm 
launchers, as necessary. 

3. Competition 

As stated earlier, competition is used to “force” coordination among the DMs. The 
competition for assets is operationalized by manipulating the tasks presented to the 
decisionmaking team so as to require assets in several places simultaneously. The two major 
command structures utilized during the scenarios were designed to allow for asset competition at 
either an orgamc or a non-orgamc level. Each scenario module represented asset competition for 
a different DM team - for example, scenario “A” presented situations that could be resolved if the 
assets were properly coordinated. The ground component units (MEUl and MEU2) 
competed for MEUl's engineer platoon and Cobras and MEU2's MEDEVAC helicopters. The 
maritime component (ARG and CVBG) competed over the ARG's Stinger platoon and the 
CVBG s Aegis cruiser, fiigate, and section of CAP aircraft. Non-organic assets that were not 
competed for, but were used in the scenario. In scenario “B” the organic and non-organic assets 
were the same (as in scenario A), however, the scenario was crafted such that organic assets were 
not competed for, while the non-organic assets were. Scenario B unfolded as did Scenario A, 
except that competition occurred in different events (i.e., "tasks"). 
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D. ABSTRACTION 


The real challenge of implementing this experiment was in the attempt to accixrately 
depict elements of the real-world and the joint environment through the use of the DDD. The 
higher level simulators examined in chapter two all contain displays with exceptionally high 
resolution of the tactical picture, which of course requires extensive software. The DDD 
simulation required that the decisionmakers be able to identify basic geography, threats and 
resources as an abstraction of the real-world. Additionally, crucial elements of command and 
control needed to be modeled. A brief description of these various abstracted elements is 
contained below: 

1. Information structure 

One of the major assmnptions behind the concept of organizational “flattening” [Ref 5] is 
the existence of a common operational picture (COP). All commanders at all levels must have a 
common view of the battle space - they must see the same threats, at the same time. Since our 
purpose was to test organizational structures in a future environment of shared, global 
information, the COP concept was a “given” for this experiment. When one decisionmaker in 
the organization saw a threat or task, it was seen by all others at the same time. It was felt that 
this common view might reduce parochialism in certain circumstances, through fostering of 
shared mental models among team members. 

The DDD-III, however, has the capability to control the amount of “shared” information 
available to the DMs. This is accomplished using the Task View command, which determines 
the team information structure for the detection and measurement of a specific task class by any 
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platform owned by a specific DM. This command can be used by the simulation designer to 
tailor the tactical picture of the DMs to model various degrees of “Global awareness”. 


Example: task view 02 2 2 2 2 2 

Format: task view id v(0) v(l) v(2) ... v(ndm-l) 

# id: integer number, uniquely identifying the task class. 

# v(I): number which specifies the degree to which the decisionmaker 

Dmi can observe this class of tasks. 

= 0: DMi cannot see a task of this class unless the task happens to be 
within the detection range of at least one of his own sensors. 

= 1: DMi can see a task of this class if the task is detected by any of the 
sensors on platforms owned by other DMS. 

= 2: DMi can see a task of this class and get attribute/class information 
if the task is within the measurement/identification ranges of any 
of the sensors on platforms owned by other DMS. 

Figure 4-1: example of task view command 


An example of task view is shown in Figure 4-1. In this instance, task class 0 task view was set 
to 2, which allowed all DMs to see a task 0 contact once in range of any platform sensor. 

2. Command structure 

Two distinct levels of orgamzational structure were used for this experiment, each with 
its own unique requirements and characteristics: 

• Three tiered: Composed of a CJTF plus a common functional 

commander, either a ground component commander (GCC) or a maritime 
component commander (MCC), supervising the two lowest-level units 
(MEUl and MEU2, or the CVBG and ARG, respectively). 
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• Two-Tiered, with the lowest-level vinits (MEUl and MEU2, or CVBG and 
ARG) reporting directly to the CJTF 

Although the two-tiered and three-tiered structures were separated for analysis, the two 
JTF organizations that were used for the experiment each had an intermediate commander 
supervising one component and none supervising the other. Thus, in half of the runs there was a 
GCC, while in the other half there was an MCC. This was done in order to keep the number of 
subjects constant across all trials, and avoid task-load-per-individual problems that would have 



arisen had the two structures been composed of different numbers of subjects. The two 
organizational structures are depicted in Figure 4-2. The command and communications 
structures were operationalized via two separate commands. 





a. Decision Structure 

The decision structure command is used to define the number of decisionmakers 
present in the simulation, as well as the command structure they are contained within, (in 
reference to the other decisionmakers) This allows the scenario designer to specify command 
structure, which affects authority/responsibility and asset control issues among decisionmakers. 
Only acyclic structures are supported in DDD~IIL 

Example: decision structure 6 

CJTF GCC MEUl MEU2 CVBG ARG 
0 0 110 0 

Format: decision structure ndm 

name(O) name(l)... name(ndm-l) 
cd(0) cd(l)... cd(ndm-l) 

Figure 4-3: example of decision structure command 

Figure 4-3 shows the decision structure assigned for one set of phase one scenarios. 

There are six decisionmakers defined for this scenario. DM1 is assigned the name CJTF, DM2 is 
assigned the name GCC, etc. This command sets the three tiered ground, two tiered marine 
structure previously discussed, with CJTF as overall commander, GCC, CVBG and ARG 
reporting to the CJTF and the two MEU’s reporting to GCC. 

b. Communications Permission 

After the command hierarchy is determined the question of conununications 
connectivity must be addressed. Although the DDD-III provides the ability to address command 
and commumcations separately, within this phase one experiment the communications abilities 
paralleled the command structure. The communications permission command sets the 



communications structure for the decisionmakers within the simulation. If a communications 


link exists from decisionmaker i to j, DMi can request/send resomces, information and 
action/intention messages to DMj. The conununications structure used for one set of phase one 
experiment scenarios is shown in Figure 4-4, 


Example: communication permission 

0 11111 
10 1111 
0 10 111 

0 110 11 

11110 1 
111110 

Format: communication permission 

P(0,0) P(0,1) ... P(0,ndm-1) 

P(1,0) P(l,l) ... P(l,ndm-1) 

P(ndm-1,0) P(ndm-l,l)... P(ndm-1, ndm-1) 

# P(ij) = 1, DMi can communicate with DMj. (i.e. link exists from I to j) 

# = 0, DMi can't communicate with DMJ. 

# Default: all diagonal elements are 0, the rest are 1 

Figure 4-4: example of communications permission command 


For this example (three tiered ground, two tiered maritime) all decisionmakers could 
communicate with each other except for MEUl and MEU2, who were forced to pass all requests 
for CJTF’s assets and messages through the GCC. This was implemented by setting all 
communications between DMs to 1, with the exception of the MEUs to CJTF connections, which 
were set to 0, preventing direct commimications. 


3. Own Forces available 

Assets owned by the five organizational entities (the sixth, the GCC/MCC depending on 
the scenario, did not directly own assets) were derived from U.S. assets currently available in the 
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real-world. Each asset had to be represented within the scenario as a platform. Those assets 
chosen and available for use in this scenario are as follows along with their initial owner: 

a. MEU(SOC)l 

One AAAV-mounted infantry company 

One V-22 Osprey-moimted helibome infantry company 

One division (4) AH-1W Cobra attack helicopters (indivisible) 

One V-22 mounted combat engineer platoon 
Naval Surface Fire Support (NSFS) from one destroyer 

b. MEU(SOC)2 

One AAAV-mounted infantry company 

One V-22 Osprey-moimted helibome infantry company 

One section (2) MEDEVAC helicopters (indivisible) 

NSFS from a second destroyer 

c. CVBG 
Aircraft Carrier 
AEGIS cruiser 

Antisubmarine Warfare (ASW)-capable fiigate 
Combat Air Patrol (CAP) section 
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d. ARG 

Two destroyers providing NSFS for MEU’s 
Amphibious ships 

One V-22 mounted Stinger platoon (indivisible) 

One section of CAP 

e. CJTF 

Two sections of close air support (CAS) aircraft 

One mine countermeasures (MCM) helicopter 

One section of SH-60 helicopters for anti-surface warfare (ASUW) 

One V-22 moimted helibome infantry company (JTF reserve) 

SR-71 photo recoimaissance mission 
One section of JFACC F-15’s for air defense 

The scenarios were designed so that if a DM must perform a specific task, then the assets 
required should be transferred to that DM, rather than the original owner attempting to perform 
the task for the unit that required the asset. For example, if MEU2 was under attack by a tank 
column, we wanted MEUl to transfer the necessary asset (the Cobra helicopters) to MEU2 to 
destroy the tanks, rather than MEUl trying to destroy the tanks itself. 

The abstraction of the assets into DDD-III platforms required that the function of the real- 
world platform be reviewed and that the value of the resources be assigned accordingly. The 
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resource vector was chosen to contain seven individual elements, corresponding to the asset’s 
ability to perform the following seven missions: 

• Air - attack air targets 

• Sea - attack sea target 

• Gmd - Attack ground targets 

• Hold - once taken, the ability to hold ground 

• Mine - the ability to sweep for mines, both land and sea 

• Armor - the ability to attack armor 

• Med - the ability to conduct medivac missions 

A listing of the platform classes and their resources is contained in Table 4-1. These 
resources reflected the relative “power” assigned to that platform class based on real-world 
capabilities of assets. For example - a land based fighter (class 2) has tremendous capability 
against air threats, but is less effective against sea and ground threats. The fighter has no ability 
to hold territory, destroy mines or conduct a medivac mission, so the value for these attributes is 
zero. All assets in the scenario were transferrable, with few exceptions. The non-transferrable 
assets included such assets as the amphibious shipping and the aircraft carrier, which were not 
directly needed to accomplish tasks. 

If the asset owner chose not to transfer an asset as requested by a DM needing it, a higher- 
level decisionmaker could force transfer of the asset(s). For example, if the ARG requested an 
asset from the CVBG, and the CVBG ignored the request, the MCC (if present) or CJTF could 
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forcibly transfer the asset from the CVBG to the ARG, if he determined that the ARG’s need for 
the asset outweighed that of the CVBG. 


Assigned Resources Values 







# Platform name 

Air 

Sea 

Gmd 

Hold 

Mine 

Armor 

Med 

0 Test platform 

50 

50 

50 

50 

50 

50 

50 

1 Carrier Fighter 

5 

2 

0 

0 

0 

0 

0 

2 Land based fighter 

5 

1 

1 

0 

0 

0 

0 

3 Carrier strike 

0 

5 

5 

0 

0 

5 

0 

4 MCM Helicopter 

0 

0 

0 

0 

5 

0 

0 

5 ASUW helicopter 

0 

6 

0 

0 

0 

0 

0 

6 Cobra helicopter 

0 

0 

5 

0 

0 

10 

0 

7 Huey helicopter 

0 

0 

5 

5 

0 

0 

0 

8 Huey (medivac) 

0 

0 

0 

0 

0 

0 

5 

9 engineering platoon 

0 

0 

0 

0 

5 

0 

0 

10 Recon aircraft 

0 

0 

0 

0 

0 

0 

0 

11 Standard missile 

5 

1 

0 

0 

0 

0 

0 

12 NSFS mission 

1 

1 

5 

0 

0 

2 

0 

13 Stinger Det 

6 

0 

0 

0 

0 

0 

0 

14 FFG(ASW platform) 

1 

5 

0 

0 

1 

0 

0 

15 Carrier 

1 

1 

0 

0 

1 

0 

0 

16 CG(AAW platform) 

1 

1 

0 

0 

1 

0 

0 

17 DDG (NSFS platform) 

1 

1 

0 

0 

1 

0 

0 

18 DDG (NSFS platform) 

1 

1 

0 

0 

1 

0 

0 

19 Amphibious platform 

1 

1 

0 

0 

1 

0 

0 

20 Amphibious platform 

1 

1 

0 

0 

1 

0 

0 

21 Amphibious platform 

1 

1 

0 

0 

1 

0 

0 

22 LCAC 1 

0 

0 

0 

0 

0 

0 

0 

23 LCAC 2 

0 

0 

0 

0 

0 

0 

0 

24AAAV 

0 

0 

5 

5 

0 

1 

0 

25 Shore bases 

0 

0 

0 

0 

0 

0 

0 

Table 4-1: Assigned values of Platform resource vectors 


/ Subplatform structure 

Some of the platforms available to the DMs were represented as subplatforms, 
representing real-world asset structure. Figure 4-5 shows the assignment of subplatforms to 
platform used in this phase experiment. The number of subplatforms available to the DM was a 
combination of real-world capabilities and the desire to drive competition for the assets. A more 
detailed description of the platform Subplatform command can be found in chapter five. 
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#Aircraft carrier carrying: fighters, Combat Air Support(CAS), anti-ship helicopters 
platform Subplatform 15 3 
VF VA H60 

3 2 1 

4 0 0 

# 

# Cruiser carrying: SAM missiles 
platform Subplatform 16 1 

SAM 

10 

-1 

# 

# Destroyer 1 (MEU 1 asset) carrying 5 Inch fire mission 
platform Subplatform 17 1 

51 

10 

2 

# 

# Destroyer 2 (MEU 2 asset) carrying 5 Inch fire mission 
platform Subplatform 18 1 

51 

10 

3 

# 

# amphibious ship (MEUl) carrying: AAAV and attack/troop/engineer helicopter 
platform Subplatform 19 3 

HCB HTP HE 
111 
2 2 2 

# 

# amphibious ship (MEU2) carrying: troop/medivac/engineer helocopter 
platform Subplatform 20 3 

HTP SD HMV 

1 1 1 

3 5 3 

# 

# amphibious ship (CJTF) carrying : mine-countermeasure helicopter/troop helicopters 
platform Subplatform 21 2 

MCM HTP 
1 1 

0 0 

# 

# sigonella base providing: Fighters, reconnaissance 
platform Subplatform 25 2 
F15 SR7 
1 1 
0 0 


Figure 4-5: example of Subplatform assignment for the scenario 
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4. Enemy forces presented 


The scenario was designed so that each threat (or "task" to be accomplished) could be 
defeated (or accomplished) by only one asset in that given situation. This "matching" of assets to 
tasks was done in order to induce the proper competition, and internal coordination, among the 
DMs for limited JTF assets. The DMs were briefed prior to the game and understood the 
relationship between various threats and the assets needed to properly engage that threat. 

a. Threats presented to the landing forces 
Mine fields offshore of one or both beaches 
One or more company-sized armored units 

Mine fields on roads (swamps restrict off-road travel) 

A number of artillery strong points 
Possible hidden FROG surface-to-surface missile launchers 
Heavy mortar platoon in range of Red Beach and port 
Infantry imits defending the port and airfield 

b. Threats to the maritime forces 
One or more Alfa-class submarines 

MI-24 Hind and fixed wing aircraft, capable of anti-ship actions 
Fast patrol boats 

One or more hidden Silkworm anti-ship missile launchers 
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The abstraction of the threat into DDD-III tasks required that the function of the 
real-world platforms be reviewed and that the value of the task attributes be assigned 
accordingly. These attributes reflect the difficulty of the task as well as the relative importance. 
Through the mapping discussed in section 5 of this chapter, the attributes were coupled to the 
resources required. For our scenario the assigned attributes for twenty-three task classes are 
shown in Table 4-2. 


# Task name 

Value 

Time 

! Air 

Sea 

Gmd Hold Mine 

Armor Med 

Enemv 

0 Hills 


10.0 

20.0 

0.0 ( 

3.0 ; 

5.0 0. 

0 0. 

0 0. 

0 0.0 

1 Airport 

30.0 

20.0 

0.0 

0.0 

10.0 

0.0 

0.0 

0.0 

0.0 

1.0 

2 Seaport 

30.0 

20.0 

0.0 

0.0 

10.0 

10.0 

0.0 

0.0 

0.0 

1.0 

3 Hold ground 

0.0 

10.0 

0.0 

0.0 

0.0 

5.0 

0.0 

0.0 

0.0 

1.0 

4 Take ground 

10.0 

10.0 

0.0 

0.0 

5.0 

0.0 

0.0 

0.0 

0.0 

1.0 

5 Artillery 

2.0 

10.0 

0.0 

0.0 

0.0 

0.0 

0.0 

2.0 

0.0 

1.0 

6 Frog Launcher 

10.0 

20.0 

0.0 

0.0 

0.0 

0.0 

0.0 

5.0 

0.0 

1.0 

7 Silkworm 

15.0 

20.0 

0.0 

0.0 

0.0 

0.0 

0.0 

5.0 

0.0 

1.0 

8 mines (land) 

5.0 

10.0 

0.0 

0.0 

0.0 

0.0 

2.0 

0.0 

0.0 

1.0 

9 mines (sea) 

5.0 

10.0 

0.0 

0.0 

0.0 

0.0 

2.0 

0.0 

0.0 

1.0 

10 Strike air 

15.0 

20.0 

5.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

11 TAC air 

4.0 

20.0 

5.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

12 Helicopter 

15.0 

10.0 

5.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

13 neutral air 

10.0 

10.0 

2.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

14 Tanks 

5.0 

10.0 

0.0 

0.0 

0.0 

0.0 

0.0 

10.0 

0.0 

1.0 

15 Neutral (gmd) 

10.0 

10.0 

0.0 

0.0 

2.0 

0.0 

0.0 

0.0 

0.0 

0.0 

16 Patrol boat 

15.0 

10.0 

0.0 

5.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

17 Submarine 

15.0 

10.0 

0.0 

5.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

18 ASCM 

15.0 

10.0 

0.0 

5.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

19 Neutral sea 

10.0 

10.0 

0.0 

2.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

20 Medivac 

5.0 

60.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

5.0 

0.0 

21 Swamp 

2.0 

10.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

22 Silkworm (air) 

15.0 

20.0 

0.0 

0.0 

0.0 

0.0 

0.0 

5.0 

0.0 

1.0 


Table 4-2: Assigned values of task attribute vectors 


5. Mapping of Resources (own forces) to Attributes (enemy forces) 

A basic element of the experiment was competition between DMs over assets necessary 
for completing a given task or series of tasks. A mechanism was required to couple the resources 
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required to prosecute a task with that tasks’ attributes. Based on the expected paths taken in the 
scenario, the platforms provided and the threats presented, the attribute and resource vectors were 
tailored to force specific platform/threat match-ups. Although the DDD-III allows any asset to 
attack any threat, as long as the appropriate flags are set, full points are only awarded when the 
threat is attacked by assets having the correct match-up of resources to those required. 

This “mapping” of threat attributes to resources required was accomplished using the 
task mapping command. This command specifies a linear mapping from the attributes of a task 
class to the resource requirements for a successful attack on that class . Figure 4-6 provides an 
example of the command. 


Example: 


task mapping 0 


0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 

0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 

0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 

0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 

0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 

0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 1.00 


Format: task mapping id 

A(l,l) A(l,2) ... A(l,natt) B(l) 

A(2,l) A(2,2) ... A(2,natt) B(2) 

A(nres,l) A(nres,2) ... A(nres,natt) B(nres) 


Figure 4-6: Example of task mapping command 


This structure of the mapping for the resource vector allows for an assignment of attribute 
values to resource values and for the addition of a constant. This allows the simulation designer 
to control the resource match up between tasks and platforms, which enables a representation of 
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the differences in firepower and engagibility found in the real-world. The specific assignment of 
attributes to resources for the scenario is shown in Figure 4-7. 


Attributes Resources 


# 

Name 

# 

Name 

1 

Value 



2 

Time 



3 

Air 

1 

Air 

4 

Sea 

2 

Sea 

5 

Ground 

3 

Ground 

6 

Hold 

4 

Hold 

7 

Mine 

5 

Mine 

8 

Heavy/armor Task 

6 

Heavy/armor 

9 

Medivac 

7 

Medical 

10 

Enemy (Recon) 




Figure 4-7: Attribute to Resource assignment 


For example, the VA, or strike aircraft platform, was the only asset with the correct resource 
values to attack the frog launcher, thus causing possible competition between the DMs over that 
asset. This example is shown in Figure 4-8. The armor resource of the strike aircraft was set to 
5.0, which matched the armor attribute of the Frog launcher. Because the mapping of the armor 
resource to attribute was one-to-one, any attack on the frog launcher by a VA aircraft would be 
considered successful. 


Value 

Time 

Air Sea Gmd Hold Mine Armor Med Enemv 

Frog Launcher 10.0 

20.0 

0.0 0.0 0.0 0.0 0.0 5.0 0.0 1.0 



Air Sea Gmd Hold Mine Armor Med 

VA (strike aircraft) 


0.0 5.0 5.0 0.0 0.0 5.0 0.0 


Figure 4-8: Resource and attribute vector comparison 
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V. DDD-III EXPERIMENT PHASE I - SIMULATION DEVELOPMENT ISSUES 


As in most computer simulations the challenge to the simulation designer is to 
model the “real”, physical world within the software world. From an experimental 
viewpoint it is crucial that the model operate according to real-world rules. A major 
artificiality can cause unwanted deviations in the results. It is equally important that the 
displays mimic as closely as possible the information provided in the real-world. Many 
unique applications of the generic DDD-III commands were developed in order to 
represent the Joint world as accurately as possible. Elements of the real-world needed to 
be abstracted that did not fit the generic mold of a direct threat - such as geographic 
features and stand-off weapons. The challenge was to model these elements without 
extensive software modifications or complex conunands that would consume the scenario 
designer’s time and distract from the true goal of the simulation. 


A. GEOGRAPHY 

Since nearly all simulation information is provided to the DMs via a monitor 
display, it is important firom a playing point of view that the display be both 
understandable and reasonable. For the results of the experiment to be valid it is also 
important that the display mimic the information provided in the real-world. Some 
elements of the display were easy to model - land and sea areas were created with little 
modification to the existing software. Others, however, were fairly complex to represent 
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and required work around solutions to be developed. Several of the more important 
geographic representations are covered below. 

1. Beachhead 

The scenario’s general premise, that an amphibious landing would be the primary 
method of putting troops on the ground, required that a beachhead landing area be 
provided to the DMs. Additionally, the designers needed to “force” the location of the 
landing areas to set up follow-on engagements, (i.e. a starting point). From a practical 
point of view, the beach areas needed to be clearly defined so that the MEU commanders 
had an idea of where they could place elements ashore. Finally, we knew that during the 
scenario elements of the MEU would remain at the beachhead, in order to perform 
medivac tasks; the enemy would target these elements, using the beaches as target areas 
for artillery attacks. 

We chose to implement the beach areas as penetration zones, which clearly 
indicated to the DMs where the beaches were located and allowed a method for 
monitoring and scoring of attacks by enemy forces. Via the task penetration the beach 
penetration zone(s) were set to be sensitive to only artillery and Frog missile task classes, 
which represented forces used by the enemy against the landing area. At various preset 
times during the scenario an artillery threat would appear, which if not suppressed would 
(after a set period of time) attack the beach area. The penetration zones and sensitivities 
are shown in Figure 5-1. 
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# - 

penetration number 7 
#- 

penetration zone circle 0 25.00 45.00 5.00 ( port area) 

penetration zone rectangle 2 26.5 70.00 4.00 6.0 ( beach area one) 
penetration zone rectangle 3 26.5 80,00 4.00 6.0 ( beach area two) 
penetration zone circle 4 5.00 95.00 5.00 (Airfield) 
penetration zone circle 5 70.00 15.00 7.00 ( fleet area (CVN)) 

penetration zone circle 6 64.00 75.00 4.50 ( fleet area amphib)) 

# 

# - 

task penetration 0 0000000 (hill mission) 


task penetration 5 0 0 1 10 0 0 (artillery) 
task penetration 6 0 0 1 10 0 0 (frog missile) 


task penetration 23 0000000 (silkworm - launcher) 

# - 

Figure 5-1: Example of penetration zone command with task penetration defined 


Other areas also implemented as penetration areas were the port and airfield, as 
well as the two fleet areas located around the CVBG and the ARG. This provided an easy 
method to target fiiendly forces with various enemy threats, such as the silkworm missiles 
and tactical aircraft. 


2. Cities 

In the earlier DDD-II paradigm there were no enemy “bases”. The simulation 
only allowed the DMs to defend areas, not to go on the offensive. This was not 
acceptable in the DDD-III paradigm. We needed to abstract the mission objectives of a 
typical Joint military scenario, which included offensive or strike capability or movement. 
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The scenarios in the experiment included several cities, an airport and a port 
facility, all of which would be important to the amphibious landing forces. The cities 
were relatively passive representations - the only requirement was that they exist. The 
scenario required that the DMs discriminate between real and “false” silkworm launchers 
within the cities to complicate the strike issue (i.e., minimiz e civilian casualties). 

#. - 

draw rectangle 27.0 49.5 2.5 4.0 
draw rectangle 27.0 64.5 2.5 4.0 
draw rectangle 27.0 87.0 2.5 4.0 
#.- 

Figure 5-2; Example “cities” using draw rectangle 
command 

As shown above in Figure 5-2, the cities were displayed as small rectangles, their 
locations included in the OPORDER brief presented to the decisionmaking team prior to 
the start of the scenario. 

3. Port/Airport areas 

The airport and seaport required a more extensive representation than did the 
cities. Both the city and the port were final mission objectives, so the implementation 
method needed to not only provide a visual reference for the DMs but also to specify the 
resources required to take the mission objective. The port and city needed to be set up as 
individual tasks to be accomplished, thus providing a mechanism to record team mission 
completion. The solution was to create a separate task class for each objective. 
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# task 1: ground mission (airport) 

task general 1 G AP 0.00 0.211 9dullas.icon 

task mean 1 30.0 10.0 0.00 0.00 10.00 10.00 0.00 0.00 0.00 1.0 

task view 12 2 2 2 2 2 

task stealth 1 0 100.0 100.0 100.0 00.0 0.0 

task stealth 1 23 100.0 100.0 100.0 00.0 0.0 
task attack 1 1 111111 

# 

# task 2: ground mission (seaport) 

task general 2 G SP 0.00 0.211 9 norfolk.icon 

task mean 2 30.0 10.0 0.00 0.00 10.00 10.00 0.00 0.00 0.00 1.00 

task view 2 2 2 2 2 2 2 

task stealth 2 0 100.0 100.0 100.0 00.0 0.0 

task stealth 2 23 100.0 100.0 100.0 00.0 0.0 
task attack 1 1 111111 

# - 

Figure 5-3: Example of mission tasks (Airport and Seaport) 


Figure 5-3 shows both the airport and seaport task classes created. The task 
classes created had no velocity and were in a fixed location. The threat flag assigned was 
a 9, which indicated to the scenario generator that both tasks represented missions to be 
accomplished. Unique icons were used for both the airport and the seaport. The task 
view command, as well as the task stealth command, were set so that the city and port 
were known and visible to all DMs throughout the entire scenario, since the location of 
major cities would be known to the forces landing. 

Each task class required a unique combination of ground and helibome assets to 
properly complete the task, which was done by using the task mean command to assign 
unique values for the air and ground attributes. The values assigned assured that the two 


59 






groxmd force DMs, MEUl and MEU2, would require additional assets to complete their 
missions, creating possible competition between the DMs. 

4. Land obstacles 

We wanted to closely model the real world environment encountered by troops, 
which would contain roads, impassible areas, hills, etc. Additionally we bad an 
experimental requirement - the two ground forces needed to advance towards their 
objectives, and reach them, at roughly the same time. A mec hanism was needed to 
prevent a “mad dash” to the objective by the ground forces. There obviously would not 
be any competition of assets if the forces were so out of S5mc that one could use the 
needed asset, while the other force was still on the beach. This “slowdown” of the forces 
was accomplished as follows; 

a. Roads 

The primary mechamsms employed to “channel” the ground forces were 
roads, connecting the beaches to both the airport and the seaport. The teams were 
briefed, via OPORDER, that off-road travel was prohibited and that the ground was to be 
considered impassable. A line drawing command, which gave the designer the ability to 
draw lines between sets of XY coordinates, was added to the DDD-III to provide the 
ability to represent the roads in the scenario. 
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b. Swamps 

After the roads were clearly defined the question still remained how to 
ensure the ground units would travel only on the roads. Though there was a chance that 
the teams would choose to remain on the road without incentive, it was felt that a 
mechanism was needed to make the land truly impassable, ensuring compliance with the 
OPORDER. The general philosophy used was to make leaving the road a bad choice, 
but not an asset killer or game ender. A penalty (loss) would be assigned to the team, 
regardless of which DM caused the violation. The penalty was large enough to be 
annoying but small enough that overall performance measures would not be skewed. 
Implementing this impassability condition required tailoring a task class to represent a 
“swamp” threat, shown in Figure 5-4. 


# task 21: Swamp 

task general 21 G SM.OO 0.211 2 swamp.icon.no_label 

task mean 21 2.0 10.0 0.00 0.00 20.00 0.00 0.00 0.00 0.00 0.00 

task view 21 2 2 2 222 

task stealth 21 0 100.0 100.0 100.0 00.0 0.0 


task stealth 21 21 100.0 100.0 100.0 00.0 0.0 
task stealth 21 24 100.0 100.0 100.0 00.0 2.0 
task stealth 21 25 100.0 100.0 100.0 00.0 0.0 
task attack 21 1 111111 
#- 

Figure 5-4: Example of swamp task class definition 


Task class 21, the “swamp”, was of type G (ground) and had 0 velocity. Using 
the stealth command (discussed further in this chapter) the swamp task was assigned a 
be-attack radius of 2 miles for ground units. This allowed us to spatially distribute the 
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tasks, creating an area of impassability without completely covering the display with 
swamp icons. The assigned value for the penalty of contacting a swamp icon was 2.0 - 
very small compared to other task values. The swamps had an attack radius of 0 miles - 
the task could not be attacked by any platform. This effectively prevented the ground 
umts from “clearing” their way across the land area by destroying the swamps. (Which is 
not an option in the real world). 

In the real world swamps would be a known quantity to a ground force prior to 
landing. To ensure that the swamps location was known to the DM’s prior to the 
amphibious landing, the detection and identification ranges for all platfo rms was set to 
100 miles for the swamp task class. This resulted in all DM’s, even if not directly 
involved in the ground action, knowing the location of the swamp areas. Full knowledge 
of the exact geographic features in a foreign coxmtry, by a landing force, is a bit 
optunistic, but for this simulation the artificiality can be overlooked. The swamp’s most 
important function was to “channel” the landing forces into a specific route, guaranteeing 
a minimum time to reach the objectives. The swamp coverage was sufficient and the 
penalty severe enough that the ground umts did in fact remain on the roads, a result of 
which was that the pretimed mission events went well. 

The combination of roads, cities, seaport, port and swamp icons located in the 
land area made for a rather full, but not overly cluttered display. Once briefed in regards 
to the land area representation, using the tutorial contained in Appendix B, the simulation 
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subjects acting as DMs had no trouble negotiating the represented geographic features. 
An example of the land area display is contained in Figure 5-5. 



B. PLATFORMS 

Numerous issues relating to platforms developed during the planning stage for the 
phase one experiment. Most platforms were fairly easy to represent using the DDD - 
assets such as fighters, tanks and ships had a “known” capability that did not change 
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much from platform to platform. Platform design followed a fairly set pattern. The 
scenarios generally called for assets based on what is currently available to the CJTF in a 
typical regional conflict. There were, however, several platforms that required additional 
development. 

1. Reconnaissance platform 

In order to force ground elements to compete for non-organic assets we placed all 
reconnaissance assets under the ownership of the CJTF. An SR71 reconnaissance asset 
was the only asset capable of determining whether a silkworm missile site was a real site 
or a decoy. Based on this information, gathered by the SR7 platform, a decision would 
be made by the DM to attack or ignore the threat. The reconnaissance platform command 
is shown in Figure 5-6. 


# platform 10: recon aircraft 
platform general 10 A SR7 0.50 1 


platform resource 10 0000000 


platform range 10 
25.00 20.00 15.00 0.00 0.01 

50.00 50.00 45.00 0.00 0.01 

50.00 50.00 45.00 0.00 0.01 

platform accuracy 10 
0.000 0.000 0.000 0.000 0.000 0.000 
0.000 0.000 0.000 0.000 0.000 0.000 
0.000 0.000 0.000 0.000 0.000 0.000 
# 


0.000 0.000 0.000 0.000 

0.000 0.000 0.000 0.000 

0.000 0.000 0.000 0.000 


Figure 5-6: Example of the SR7 Platform Class 
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To implement this identification ability the SR71 task class needed a unique 
capability - the ability to measure the value of the “enemy” attribute, ajo, contained in the 
task attribute vector. The SR7 platform was given this ability using the platform 
accuracy command. The SR7 was given the ability to “see” the attribute - all other 
platforms were unable to measure this value of the attribute vector, as their platform 
accuracy on attribute a,o was set to -1, which prevented measurement of that attribute. 

2. Platform reusability 

The issue of whether a platform could be xised more than once became important 
when trying to set a time line for task accomplishment by the team. The ability to induce 
competition within the team depended on the nvimber of assets available at any given 
time. Two mechanisms were used to control the assets available: 

a. Endurance/returnability 

The endurance of a (sub)platform is set in the platform general command. 
This command specifies how long a subplatform exists once it has been launched. The 
endurance specification is germane to the scenario generator only in the case of a 
subplatform, but since fire scenario generator allows any platform to be designated as a 
subplatform the endurance must be defined for all platform classes. If the platform class 
is not designated as a subplatform the endurance of the asset would be for the entire 
scenario period by default. Some assets used as subplatforms, such as fighters and attack 
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aircraft, had a limited endurance period after which they would return to their point of 
origin (i.e. carrier, base, etc.) 

Whether the asset could be launched again was determined by the retumability 
flag, also set in the platform general command. The intent here was to model cycle 
times such as in aircraft operations, which in the real-world limits the air assets available 
at any given time. 

b. Reusable flag 

The life span of “consumable assets”, such as fire support rounds and 
missiles, was too hard to predict with any accuracy, so the endurance value was not much 
good - another method to limit use was needed. The reusable flag, also set in the 
platform general command, provided for “single use” subplatforms to be made available. 
If the subplatform was used to attack a task this flag determined whether or not the asset 
would still be available after the attack was complete. The reusable flag was most useful 
with the “consumable” assets, such as surface to air missiles or naval surface fire support 
rounds. One “consumable” asset used in the scenario was Naval Surface Fire Support 
(NSFS). This subplatform represented a “fire mission”, vice a single round from a gun, 
but the concept of reuse still applied. When requested from the supporting surface ship, 
the fire mission subplatform was available for a limited time. Once used, the number of 
NSFS missions available to the MEU decreased by one - limitin g the number of missions 
available to the DM, much like the real-world. An example of reusable flag use is shown 
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in 5-7. The reusable flag in the platform general command is set to zero, indicating the 
platform was a single use “consumable” asset. This resulted in the 51 platform 
disappearing along with the destroyed task. Amplification of the platform general 
command can be found in Appendix A. 


# platform 12: ship based NGFS support rounds 
platform general 12 A 51 0.00 0 
0 0 60.00 3.000 10.000 
platform resource 12 1150020 

platform range 12 
0.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 
45.00 0.00 0.00 40.00 0.00 
platform accuracy 12 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

Figure 5-7: Example of the NSFS platform used as a subplatform 


3. Subplatform ownership - location vs command hierarchy 

Subplatform ownership became a critical issue during the implementation phase 
of the scenario design. The scenario called for subplatforms to reside on a platform until 
needed, then to be launched by the platform owner. The initial version of the DDD-III 
automatically assigned ownership of the subplatform to the DM who owned the parent 
platform . This made the abstraction of theater assets extremely difficult. There was no 
way to represent subplatforms, owned by one DM, that resided on a platform owned by 
another DM, such as theater assets stationed on the carrier. The command platform 
subplatform was developed to allow full flexibility in regards to subplatform ownership. 
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This command specifies the number of subplatform classes that a specific platform class 
could have, as well as which subplatform classes (by name), and how many were 
contained on each platform. Additionally, and perhaps most importantly, the command 
specifies the ownership of the subplatform following launch, allowing the designer to 
place assets on platforms but retaining ownership with a second DM. The structure of 
this command is shown in Figure 5-8. 


Format: platform subplatform id num 

sub_class(l) sub_class(2)... sub_class(num) 

1^(1) n(2) ... n(num) 

owner(l) owner(2) ... owner(num) 

# id: integer, giving the unique identification of the parent platform class. 

# num: integer, indicates the number of subplatform classes that this platform class has, max=7 

NOTE; The maximum number of subplatforms that can be 'on-screen' at any one time is 100. 

# sub_class(i): the name of the subplatform class. This name must be one of the class given in an 

earlier platform general command. 

NOTE: The platform and subplatform classes must be defined (via the platform general 
command) 

BEFORE the definition of their nesting structure. 

# n(i): the number of individual subplatforms of class 'sub_class(i)' on board this platform class. 

# ownetfi): the number of the decisionmaker who will own the individual subplatforms of class 

'sub_class(i)' when they are launched. 

NOTE: If owner(i)= -1 these subplatforms will be owned by whomever “owns” the parent 
platform 

e.g. this gives the designer the ability to model self defense weapons. 

NOTE: The default is no subplatforms present on platforms 

Figure 5-8: Example of platform subplatform nesting structure 
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Example: platform subplatform 15 3 

VF VA H60 

3 2 1 

4 0 0 

Figure 5-9: Example of platform subplatform command use 

In the example of platform subplatform shown in Figure 5-9, each parent platform 
of platform class 15 (an aircraft carrier) will have three subplatform classes (children) 
onboard. The three subplatform classes are VF(fighter aircraft), quantity 3, owned by 
DM4 (the CVBG commander); VA (strike aircraft), quantity 2, owned by DM0 (the 
CJTF commander); and H60 (helicopters), quantity 1, also owned by DM0. 


C. TASKS 

1. Specific task issues (‘indirect” threats) 

Most threats were relatively easy to model - they entered the tactical picture, 
maneuvered through the region towards a target objective (most often a penetration zone) 
and attacked, if not stopped by the team. To accurately model the real-world, however, 
several classes of tasks were needed to represent the so-called indirect threats - contacts 
that appeared in one area but were actually a threat to friendly forces in another area. 
Examples of this type of threat are artillery and silkworm missiles. 
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a. Artillery 

The scenario required enemy artillery units to appear within the general 
vicinity of the ground forces and target friendly positions. If left unmolested the artillery 
would eventually fire on the beachhead landing areas. An objective of the JTF 
organization was to suppress the artillery positions prior to actual fi ring , protecting any 
assets on the beaches. An example of the task class artillery is shown in Figure 5-10. 


# 

# task 5: ground contact (artillery) 

task general 5 G AT .99 0.211 2 artillery.icon 

task mean 5 2.0 10.0 0.00 0.00 0.00 0.00 0.00 2.00 0.00 1.00 


task view 5 2 

2 

2 2 2 2 



task stealth 

5 

0 

100.0 100.0 100.0 100.0 00.0 

task stealth 

5 

1 

00.0 

00.0 

00.0 

5.0 00.0 

task stealth 

5 

2 

00.0 

00.0 

00.0 

5.0 00.0 

task stealth 

5 

3 

00.0 

00.0 

00.0 

8.0 00.0 

task stealth 

5 

4 

00.0 

00.0 

00.0 

00.0 00.0 

task stealth 

5 

5 

00.0 

00.0 

00.0 

00.0 00.0 

task stealth 

5 

6 

00.0 

00.0 

00.0 

6.0 00.0 

task stealth 

5 

7 

00.0 

00.0 

00.0 

5.0 00.0 

task stealth 

5 

8 

00.0 

00.0 

00.0 

00.0 00.0 

task stealth 

5 

9 

00.0 

00.0 

00.0 

00.0 00.0 

task stealth 

5 

10 

100.0 

50.0 

50.0 

00.0 00.0 

task stealth 

5 

11 

00.0 

00.0 

00.0 

00.0 00.0 

task stealth 

5 

12 

50.0 

50.0 

50.0 

50.0 00.0 

task stealth 

5 

13 

00.0 

00.0 

00.0 

00.0 00.0 


task stealth 5 23 00.0 00.0 00.0 00.0 00.0 
task stealth 5 24 50.0 50.0 50.0 5.0 00.0 
task attack 5 1111111 

Figure 5-10: Examples of artillery task class 


To allow for the ground units to see the artilleiy task a task stealth command was used to 
modify the ground ranges for the MEU ground forces (Task class 24, the AAAV, is 
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modified with the Task stealth 5 24 line above). The ranges of the 51 platform and the 
DDG offshore were also modified to allow for engagement (task stealth 5 10 and 5 12). 

The team was constrained to the use of a single particular asset, Naval Fire 
Support (NFS) to suppress the artillery threat. This was accomplished by exclusively 
mapping the attribute vector of the artillery task class to the resource vector of the NFS 
platform class (5In). The 51 platform is shown in example 5-11. 


# platfomi 12: ship based NGFS support rounds 
platform general 12 A 51 0.00 0 

0 0 60.00 3.000 10.000 
platform resource 12 1 1 5 0 0 2 0 

platform range 12 
0.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 
45.00 0.00 0.00 40.00 0.00 
platform accuracy 12 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

Figure 5-11: Example of 51 platform class 


In order to provide enough time for engaging the artillery threat the maneuver 
commands were spaced in time to present the threat throughout the game. Each artillery 
task icon would appear and wait for 300 seconds before moving at a high velocity to “hit” 
either the north or south beach. Artillery tasks were spaced in time to arrive every 400 
seconds for the north beach, every 300 seconds for the south beach. The specific 
maneuver commands for a series of eight artillery attacks on the north and south beaches 
are shown in Figure 5-12. 
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# Tasks 241-250 (artillery) 

# Artillery positions: site one: 

# site two: 

# 

maneuver definition 241 500.0 
s 12.0 67.0 300.0 
m 12.0 67.0 0.99 
e 27.5 82.5 0.0 

# 

maneuver definition 242 900.0 
s 12.0 67.0 300.0 
m 12.0 67.0 0.99 
e 27.5 82.5 0.0 

# 

maneuver definition 243 1300.0 
s 12.0 67.0 300.0 
m 12.0 67.0 0.99 
e 27.5 82.5 0.0 
# 

maneuver definition 244 1700.0 
s 12.0 67.0 300.0 
m 12.0 67.0 0.99 
e 27.5 82.5 0.0 

# 


(12.0 67.0-north) 
(15.0 88.0-south) 


maneuver definition 246 600,0 
s 15.0 88.0 300.0 
m 15.0 88.0 0.99 
e 27.5 72.5 0.0 

maneuver definition 247 930.0 
s 15.0 88.0 300.0 
m 15.0 88.0 0.99 
e 27.5 72.5 0.0 

maneuver definition 248 1230.0 
s 15.0 88.0 300.0 
m 15.0 88.0 0.99 
e 27.5 72.5 0.0 

maneuver definition 249 1530.0 
s 15.0 88.0 300.0 
m 15.0 88.0 0.99 
e 27.5 72.5 0.0 


Figure 5-12: Example of artillery task class maneuvering commands 


b. Silkworm sites 

The scenario had a need for a threat that would require C JTF 
reconnaissance assets (or a national asset) to provide positive identification prior to 
prosecution. A Silkworm missile threat was chosen to fill this requirement. The 
description of the groimd task class silkworm is shown in Figure 5-13. 
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# task 7: ground contact (silkworm anti-ship missile battery) 
task general 7 G SWG 0.99 0.211 1 sillworm.icon 
task mean 7 15.0 20.0 0.00 0.00 0.00 0.00 0.00 5.00 0.00 1.00 
task view 7 2 2 2 2 2 2 


task stealth 

7 

0 

100.0 100.0 100.0 

0.0 

0.0 

task stealth 

7 

1 

0.0 

0.0 

0.0 

5.0 

0.0 

task stealth 

7 

2 

0.0 

0.0 

0.0 

5.0 

0.0 

task stealth 

7 

3 

0.0 

0.0 

0.0 

8.0 

0.0 

task stealth 

7 

4 

0.0 

0.0 

0.0 

0.0 

0.0 

task stealth 

7 

5 

0.0 

0.0 

0.0 

0.0 

0.0 

task stealth 

7 

6 

0.0 

0.0 

0.0 

6.0 

0.0 

task stealth 

7 

7 

0.0 

0.0 

0.0 

5.0 

0.0 

task stealth 

7 

8 

0.0 

0.0 

0.0 

0.0 

0.0 

task stealth 

7 

9 

0.0 

0.0 

0.0 

0.0 

0.0 

task stealth 

7 

10 

50.0 

50.0 

50.0 

0.0 

0.0 

task stealth 

7 

11 

0.0 

0.0 

0.0 

0.0 

0.0 

task stealth 

7 

12 

0.0 

0.0 

0.0 

0.0 

0.0 

task stealth 

7 

13 

0.0 

0.0 

0.0 

0.0 

0.0 

task stealth 

7 

14 100.0 

0.0 

0.0 

0.0 

0.0 


task stealth 7 25 100.0 0.0 0.0 0.0 0.0 

task attack 7 1 111111 

Figure 5-13: Example of silkworm task (ground) class command 


The Silkworm threat acted much like the artillery threat, appearing in a fixed land 
location, holding for a set period, then “flying” to the target (either the CVBG or the 
ARG penetration zones) in order to score a hit. To do so the silkworm threat had to cross 
the boimdary between the land area and ocean area . If an air task had been used there 
would have been no problem, but we desired that the Silkworm be viewed as a ground 
threat (i.e. a silkworm launcher), so it needed to be a Ground task type. This Ground type 
silkworm threat, however, could not travel outside the land boundary, so the spawned 
Silkworm threat needed to be an Ah type task. Because of this land/sea boundary issue 
two task classes were actually used - one (ground task class) for the initial ground 
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detection and one (air task class) that was spawned, or “launched”, upon the 
disappearance of the first. The spawning implementation is described in a later section. 
A description of the air task class silkworm is shown in Figure 5-14. 


# task 22: Air contact (silkworm anti-ship missile battery) 

task general 22 A SWA 0.99 0.211 2 silkworm.icon 

task mean 22 15.0 20.0 0.00 0.00 0.00 0.00 0.00 5.00 0.00 1.00 

task view 22 2 2 2 2 2 2 

task stealth 22 0 100.0 100.0 100.0 100.0 0.0 


task stealth 22 1 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 2 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 3 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 4 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 5 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 6 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 7 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 8 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 9 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 10 

50.0 

50.0 

50.0 

0.0 0.0 

task stealth 22 11 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 12 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 13 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 22 14 100.0 

50.0 

50.0 

0.0 0.0 

task stealth 22 25 100.0 

50.0 

50.0 

0.0 0.0 


task attack 22 1 1 1 1 1 1 1 

Figure 5-14: Example of Silkworm task class (air) command 


To facilitate the use of a national or CJTF asset to conduct positive identification 
of the silkworm launch site a “positive ID attribute” was included in the attribute vector. 
This attribute was only readable by the SR7 reconnaissance asset held by the CJTF. To 
increase competition among umts the “ground” Silkworm could only be engaged with VA 
attack aircraft) owned by the CJTF. This was accomplished by again tailoring the 
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attributes of the task to the resources of the specific platform. Once “launched” the (air) 
silkworm threat could not be engaged by any platform. 


2. Spawning 

When initially written the software had no provisions for a sequential game nor 
one that allowed the simulation to “react” to various decisions of the team. It quickly 
became apparent that there was a need for a “spawning” command that allowed the 
designer to present the team with a task that when accomplished would produce another 
task, such as taking of a hilltop then the holding of the same piece of ground. 

The “launch” or spawn of the air task silkworm threat was accomplished using the 
task spawn command. An example of the command format is shown in Figure 5-15. 


Format; task spawn id num type sid(l) ... sid(5) 
sid(6) ... sid(lO) 
sid(num-4)... sid(num) 

# id: integer id of spawner' task for which new tasks will be spawned. 

# num; integer number of tasks to be spawned. 

# type: character A or D denoting a task Attack or task Disappear event. 

# sid(I): integer ids of'spawned' tasks. 

NOTE: i) 0 < num < n, where n is specified via number of tasks command. 

ii) a task can be both spawned and a spawner (ie, recursive), however, a task cannot be 
spawned by more than one spawner. 

iii) to prevent spawning cycles, ie, X spawns Y spawns X, we require id < sid(I), I = l..num. 

iv) at most 5 spawned task ids specified per line, and, for num > 5, only last line can 
have <= 5 task ids specified. 

Figure 5-15: Example of Silkworm task class (air) command 


For the silkworm transition from groimd to air the spawn was keyed to the disappearance 
of the ground task. If the ground task silkworm was not properly engaged within the wait 
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time then after a set period the air task would spawn, or “launch” and target the CVBG or 
the ARG. This spawn command is shown in Figure 5-16. 

task spawn 286 1 D 289 

# task 286 is ground task silkworm 

# task 289 is air task silkworm 

Figure 5-16: Example of Silkworm task class (air) command 


3. Stealth command usage 

The platform range command provided the mechanism for assigning sensor 
ranges, such as detection and identification. However, this command allowed for setting 
platform sensor ranges only by class type - air, sea and ground. After designing portions 
of the scenario it became apparent that the platform range command did not provide the 
flexibility needed to abstract the more complex scenario requirements. Because of the 
great number of assets and threats being umquely represented, a method was needed to 
specific task class to specific platform class range assignments. This was 
implemented using the task stealth command. The stealth co mman d resets the detection, 
measurement, identification, attack and be-attack ranges for a specific task Class vis-a-vis 
a specific platform class. (Overrides default values.) This allows the scenario designer to 
tailor ranges down to an individual threat or mission, which can be used to create the 
possibility of a late detection or non-detection of a unique threat. A description of the 
command is contained in Figure 5-17. 
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Format: task stealth idl id2 [sensor(l) sensor(2) sensor(3) attack(l) attack(2) ] 

# idl: integer number, identifying the task class. 

# id2: integer number, identifying the platform class. 

# sensor(i): floating point numbers: 

i=l: overrides sensor detection range r(j,l) of platforms of class id2 when 
encountering tasks of class idl (that are of type j) 
i=2: overrides sensor measurement range of platforms of class id2 when 
encountering tasks of class idl (that are of type j) 
i=3: overrides sensor identification range r(j,3) of platforms of class id2 when 
encountering tasks of class idl (that are of type j) 

Default: values r(j,i) as specified in platform range command — EXCEPT if threat_flg = 2 or 3, in 
which case default values “ r(j,5) 

# attack(i): floating point numbers: 

i=l: overrides associated attack range r(j,4) of platforms of class id2 when 

attacking tasks of class idl (that are of type j). Default: value = r(j,4), 
EXCEPT if threat flg = 2, in which case default value = 0.0 
i=2: overrides associated be-attacked range r(j,5) of platforms of class id2 when 
encountering tasks of class idl (that are of type j). Default: value = r(j,5) 
for 

all values of threat flag. 


Figure 5-17: Example of task stealth command 


a. Mines 

One application of the task stealth command was in the modification of 
the mine tasks, both sea and ground. The scenario OPORDER stated that mines were in 
the area of battle, but did not specify the location or number. The stealth command was 
used to set the detection range of several of the platforms to a fraction of their “normal” 
groimd ranges. The be-attack ranges were also significantly reduced. The mines would 
appear on the display only after a platform crossed into the small detection range. In 
some cases the DM had very little time to react to the threat. The speed of the platforms 
and the small difference in ranges resulted in a requirement for an immediate response by 
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the DM controlling the affected platforms. An example of the co mman d being used for 
the ground mine threat is shown in Figure 5-18. 


task general 8 GMN 0.01 0.211 2 mines.icon 

task mean 8 5.0 10.0 0.00 0.00 0.00 0.00 2.00 0.00 0.00 1.00 

task view 8 2 2 2 2 2 2 


task stealth 8 0 

100.0 

100.0 100.0 100.0 02.5 

task stealth 8 1 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 2 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 3 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 4 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 5 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 6 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 7 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 8 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 9 

00.0 

00.0 

00.0 8.0 02.0 

task stealth 8 10 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 23 

0.0 

0.0 

0.0 

0.0 0.0 

task stealth 8 24 

4.0 

4.0 

4.0 

0.0 01.0 

task attack 8 1 

mill 




Figure 5-18: Example of task stealth command used in the mine task class 


In this example platform 9 and 24 are assigned new ranges for task 8, the 


ground mine. These ranges will override the ranges set in platform range. The detection 
of the mine threat by platform 24, the ground units of MEU2, will occur at four miles, 
with the be-attack or lethal range of the mine set to one mile. All other platforms used 
in the scenario were assigned ranges of 0 to ensure that the mines would not be detected 
inadvertently by another asset, such as an aircraft passing over the area. 
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D. SPEED AND MOVEMENT 


The playing area, a 100 by 100 mile square grid, was chosen for a number of 
reasons, not the least of which was the usability of the display. If the game area were to 
be expanded much beyond 100 miles the DMs would be forced to “zoom in” much more 
frequently. It was decided that for the phase one experiment, display confusion (or a lack 
of user friendliness) should be avoided whenever possible. For this experimental reason 
the size of the display was chosen simply based on what looked the best - and allowed 
each DM to see the entire battle space without excessive command requirements. 

To place a land mass, ocean area, full carrier battle group and an amphibious 
readiness group in such a small area did pose some interesting problems. Realistically, 
no carrier battle group is going to be within 20 miles of a hostile coast, at least not imtil 
air superiority is achieved. This simulation required some constructive time/distance 
“changes” to make the assets behave more like the real world. In other words, the 
movable elements of the scenario, both assets and threats, moved the same as in the real 
world - in relation to each other . 

It was necessary on occasion to adjust the speed of the targets and assets to allow 
the various missions to be accomplished within the 40 minute simulation window - in 
some cases the scenario speeds of some imits was triple the “real world” speed. There did 
not appear to be any real problems with this modification in terms of scenario 
believability. An example of the need to change speeds was the observance (in trial runs) 
that in one of the scenarios the southern MEU was always arriving at the objective first. 
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which avoided the competition that we were trying to induce. By slowing the southern 
MEU’s speed down by just 5% we were able to ensure that both MEU’s reached their 
objectives at roughly the same time. 

E. EXPERIMENTAL CONTROL 

After the first roimd of training runs with the actual teams the length of the 
scenarios was fixed at 40 minutes. Several times during the training runs the teams 
would “finish” i.e. reach the objective/goal, prior to the end of the game clock. For the 
purposes of data taking and to support the controlled conditions of the laboratory 
environment the teams were required to remain at the consoles and perform any game 
elements imtil the clock reached 40 minutes. The simulation lacked a sense of realism 
when this situation occurred. A mechanism was needed to terminate the game following 
the completion of the mission objectives. This mechanism was implemented using the 
end game command. The end game command, shown in Figure 5-19, allowed the 
designed to specify the final mission task as a trigger for the te rminati on of the game. 

Format: game end id time 

# id: game will gracefully end after the task number id has been 

attacked. 

# time: float delay time to wait before ending the game. 

Default: id=399, time=5.0. 

Example: game end 390 5.00 

Figure 5-19: Example of end game command 
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VI. DDD-III EXPERIMENT PHASE I - FUTURE ISSUES 


Many challenges were encountered in modeling the Joint environment utilizing 
the DDD-III during the planning and development of the experiment. Many of these 
challenges were solved prior to the experiment, in an evolutionary manner, whereby 
various abstractions were developed, tested and installed in the scenario. No “show 
stoppers” were encountered, although several minor elements of the scenario, such as the 
number of NSFS ships available, were modified to be more easily represented by the 
DDD. These small modifications of the scenario, however, were transparent to the 
decisionmaking teams. As such the basic premise of the experiment and the general 
hypothesis were unaffected by these changes. 

While implementing the current scenario, additional ideas for abstracting 
elements within the DDD-III were considered for future implementation. Some of these 
concepts have been developed - others are still in the “idea” stage. The major concepts 
for future development are discussed below. (A discussion of lessons learned from the 
phase one experiment is also contained in additional documents [Ref 8].) 

A. INFORMATION STRUCTURE 


1. Information net design 

The information structure currently available in the DDD-III is of a single “net” 
design. Data is available to all decisionmakers as long as the individual platform sensor 
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is capable of reading the data. The scenario designer has a limited ability to tailor the 
information received by the individual DMs. Some degradation of the data is possible via 
the various “noise” inducing commands, but again, this data must be readable by the 
platform sensor. The Joint information structure in the real-world, however, is composed 
of a multitude of information nets, separated by function, geography and mission need. 

A true abstraction of the Joint environment would give the designer the ability to 
provide different nets to different DMs. A representation of a general information net 
structure concept is shown in Figure 6-1. 

To implement this concept and accomplish the functions required for a net 
structure the task view command will be replaced with three new commands: 

• Number of nets nets 

• platform nets 

• access nets 
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The first command, number_of nets nets \^11 specify the number of information nets that 
exist in the scenario. The designer will then customize the connections between the 
platforms and the nets in order to determine the type of information available from 
sensors on a particular platform class. This connection can be representative of a low 
bandwidth device, in which case the sensor may report only detection, or a highband 
device, in which case the sensor may provide measurements of attributes. 

Finally, the designer will specify the connection between the nets and the DMs, 
determining what information will be presented to the DMS. The coimection will specify 
the type of information desired: Air, Sea, Groimd, any combination of the three. 

This method of implementation will allow for greatly increased flexibility in the 
information structure and more closely model the real-world. This net stmcture concept 
can be built upon to further enhance the information distribution throughout the scenario. 
However, there are many procedural concepts, such as: (1) the use of filters in the 
connecting lines, (2) who controls the assignment of nets and (3) who can join a net, that 
require further exploration. 

2. Information growth 

In the current version of the DDD, information presented to the DMs, in the form 
of sensor measurements from platforms, changes only with distance, (i.e. the accuracy of 
the sensor can be set to be range dependent) This creates a more accurate representation 
of sensors available in the real-world. However, there is more that could be included 
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with respect to the manipulation of data change. Information in the real-world does not 
remain stagnant but changes with time as the conditions of the enviro nm ent and of battle 
change. 

One element is that of a dynamic information environment. As the scenario 
progresses, mformation on a particular task can change to represent an increased threat or 
a capability that may not have been initially detected. 

3. Communications 

a. Internal message traffic 

The current version of DDD-III allows for message traffic among the 
DMs, although messages are limited to menu selected and pre-scripted options. During 
the course of the experiment, it became apparent that the menu selected messages were 
not sufficient for a high-level decisionmaking simulation. The limited number of 
messages constrained the flow of command and control information among the DMs, 
resulting in player frustration. 

This change is in the design phase. Whatever the method of implementation, 
there will be significant requirements on the recording of message traffic for the purposes 
of data analysis. The improved message system must at a minimum provide to the DDD 
log files the text of the message, the time sent, sender, receiver and any DMs that where 
included in the message distribution. 
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b. 


External message traffic 


An external message is informational text, originating outside the DDD 
software, which must be delivered to any or all DMs. An outside message is 
normally an intelligence report but can be anything since no restrictions are 
placed on its content. During the scenario runs the outside messages were in the form of 
paper copies handed to the DMs by experiment monitors. This was a rather cumbersome 
process, requiring coordination with the scenario time line, as well as the administration 
of all the various messages to be presented to four teams on four scenario runs. 

Future DDD-III scenarios will present “outside” messages via the message display 
system contained in the software. The scenario designer will specify message delivery 
based on time or event, and will be able to specify the desired distribution. 

B. COMMAND STRUCTURE 

1. Level of decision making 

The tasks presented to the DMs were all handled in the same manner for this 
experiment. Each DM followed similar procedures to accomplish a presented task. In 
the real-world, however, mission objectives vary based on the relative level of the DM 
involved, as well as how the objective is actually processed. For example: the objective 
of taking the beach represents a single mission to the CJTF. For the component 
commander (GCC), however, this objective involves many smaller objectives, such as 
picking the beachhead, placing troops into position, assigning covering air, etc.. The 
same broad task may appear to be very different to different levels of the same decision 
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team. This difference requires that separate parts of the team perform tasks that may be 
viewed as fundamentally different. 

One method of integrating this difference into the simulation may be to create a 
set of tasks that present a series of “subtasks” to be accomplished by DMs of varying 
decision levels. Unlike ihc prerequisite command, this set of “subtasks” would reside on 
a single task, be presented together, and not necessarily require that the “subtasks” be 
accomplished in any given order. 

C. ENVIRONMENT 

1. Geography 

The DDD-III currently uses “tasks” to represent various geographic obstacles, 
such as swamps, hills and towns. Additional environmental commands added to the 
general commands section would simplify scenario design, such as preformated swamps, 
hills, roads, etc. These environmental commands would be used to increase the richness 
of the visual display. To represent an objective to be taken by the DMs the definition and 
representation of a task class would still be required. 

D. PLATFORMS 

1. Ownership 

During the scenario, ownership of subplatforms developed into a significant issue. 
The partial resolution was development of the platform subplatform command structure. 
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which, among other elements, specified the ownership of a subplatform following its 
“launch”, (see chapter V) 

There are situations in the real-world in which two identical assets, positioned on 
the same parent platform, are owned by different Decisionmakers. An example of this for 
our scenario was NSFS - both MEU’s needed to simultaneously “own” fire missions of 
the same subplatform class (Sin) on the same ship (DDG). With this situation the 
challenge for the designer was to work around the DDD-III, which would not allow 
identical subplatforms to reside on the same platform with different owners. This 
limitation was averted by the addition of another DDG to carry the second MEUs NSFS 
missions. 

The platform subplatform command will be modified to remove this limitation. 
This will reduce the number of platforms required in the scenario and more accurately 
represent the real-world environment. 

2. Attrition 

This scenario was designed so that assets needed for mission accomplishment 
could not be destroyed, either by team error or by random chance. Attrition was 
represented by the loss of team strength - a score maintained for a final measure of 
success of the team performance. It is generally undesirable, from an experimental point 
of view, for available team assets to be a function of the team’s path through the scenario. 
Some attrition, however, would definitely be a positive step towards real-world combat 
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situations. The method of implementation and the resulting effect on the experimental 
conditions must be further researched. 

3. Loss of resources (damages) to an asset 

Closely related to attrition is the concept of mission capable platforms. One 
mechamsm to abate the attrition problem would be to allow damage to be sustained by 
platforms. The amount of damage could be limited to a final mission-representative 
figure, or “bottom line”. The implementation of this concept could result in the need for 
more assets for a given task to be accomplished. 

4. Auto-stop (intelligence) 

The current version of DDD does not contain any mechanism for a platform to 
“react” to a threat. The stealth command, used frequently in this scenario, resulted in 
several tasks “popping” up within a very short range of the platform. The platform, 
unaware of the task in its path, would of course continue on the course of action last 
ordered by the DM in control. In the real-world, however, upon detection of a threat or 
anomaly, an asset would stop and reassess the situation to determine whether new action 
is needed, before proceeding. 

To implement this “intelligent” response to a “pop-up” threat, the software will be 
modified to stop a platform upon detection of a task in its path, and possibly to engage the 
task. The specific issues of the option have yet to be determined, but there will be a 
tailored set of task parameters to trigger this “autostop” concept. 
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E. TASKS 


1. Arrival based on location vs time 

Currently, all tasks are time dependent - the scenario designer scripts the sequence 
of tasks and then uses a time line to designate arrival times. The task spawn command is 
one attempt to replace the time dependency with situational dependency, but this is only 
the first step. In the scenario, designers were concerned about maintaining the 
advancement of forces at relatively the same pace, ensuring that hoped for competition 
events would occm. The ability to have tasks sensitive to “trip wires” would have been a 
great advantage in controlling the advance. For example - tanks that appeared on the road 
were carefully timed and placed so as to “appear” to both ground forces simultaneously. 
However, in some scenario runs the beach landings did not go according to the schedule, 
and tanks appeared on the road long before the forces were actually in a position to be 
engaged by them. 

2. Dynamic tasks (attributes, etc., as a function of time) 

It would have been interesting if the attributes of the enemy ground units changed 
as the scenario progressed. Thus, depending on when the task is actually engaged by the 
DMs assets, the complexity, resources, information and coordination elements may be 
significantly altered. For example, in this scenario, enemy tanks required only one 
section of aircraft to engage and destroy them. Future design considerations include 
consideration of changing task attributes. What if, however, the attributes of the tanks 
changed with time, i.e. in a period of time the tanks are “reenforced” with additional 
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forces? They then would require addition assets to destroy them. For example two 
sections of combat aircraft, further complicating the resource allocation issues faced by 
the DMs. 


3. Parallel attacks by several DM’s (done) 

Currently, a form of parallel attacking is possible - during the scenario there were 
several tasks that required more than one platform’s assets to effectively engage and 
destroy them. This method of attacking was very constrained in the sense that the amount 
of resources required to attack was known and the platforms engaged simultaneously. 
Balancing the desired realism with the practical elements necessary to force asset 
competition virtually forced a umque task to asset association PRef 6]. This association 
is, of course, present in the real-world but in a much more flexible manner. For instance, 
a more generic requirement to engage aircraft with an anti-air weapon, vice having the 
specific weapon designated ahead of time. 

One method proposed to circumvent the unrealistic asset-task assignment is to 
allow for simultaneous attacks by platforms. The DMs would be aware of the minimum 
required resources but have the flexibility to achieve these resources by combining the 
platforms in any desired manner 

4. Unknown resources needed for engagement 

In the current DDD-III the resources required to properly engage a task are 
reported to the DMs provided there is a platform sensor within range of the taslf able to 
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measure the attributes. The ability to consistently view the match-up prior to an 
engagement is something that does not exist in the real-world. 

A more realistic representation would be for the attacking platform to have little 
or no idea as to the resources required. For instance the DM is required to engage the 
threat but does not know if he will be successful. Once the platform engages the task the 
attribute to resources match-up would be displayed. The DM might then have to call 
upon other platforms, either organic Or non-organic, to provide the necessary resources to 
make up the difference and complete the attack. This concept would be effectively 
supported by a new parallel attack command. 

5. Tasks reduced in ability following an attack 

In the current DDD-III all tasks, if engaged properly with platforms holding the 
required minimiun resources, are destroyed. The capability to reduce or degrade task 
effectiveness verses actually destroying the task (i.e. a mission kill) would allow the 
simulation to more accurately model the real-world. Many times ROE requires that a 
reeisonable and appropriate response be used by the subordinate commanders in the 
execution of their mission. 

6. Tasks warned off vice destroyed 

No mechanism currently exists to warn off a task vice engaging and destroying it. 
The realities of the real-world are seldom this final - there are rules of engagement to 
follow, plus international law and convention to abide by. In many combat areas, aircraft 
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and surface vessels are routinely warned off by the forces in the region, presenting the 
opportunity for the unknown contact to leave the area before being engaged. 


F. SPEED AND MOVEMENT 

1. Variable task speed 

Much of the movement of both task and platforms is linear. Simple grid locations 
are presented by the designer to the scenario generator, which translates these XY 
coordinates into motion vectors for the tasks. No mec hani s m exists to allow variation or 
to simulate a responsive target - the task speed is currently set to a time line. If the ability 
existed to speed the task up when a platform came into close proximity, the threat would 
be more representative of a dynamic real-world threat. 
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VII. SUMMARY 


A. PROJECT CONCEPT 

A revolution in Command and control (C2) capability, brought about by new 
communications technology and advanced computer capabilities, has created the “Global 
Awareness” concept. How Decisionmakers (DMs) adapt their organization to coordinate 
information, resources and activities to fulfill their mission, within the realm of Global 
Awareness, is the subject of current research efforts. 

The Office of Naval Research has commissioned a research effort into this far 
reaching topic - the Adaptive Architectures for Command and Control (A2C2) project. 
The project required a mechanism to abstract "real world" problems into a controlled 
laboratory environment where a variety of experimental conditions could be manipulated. 

A new program 'was needed to support this model-based empirical research. The 
result was the development of the Distributed Dynamic Decisionmaking (DDD-III) 
paradigm. 

B. DISTRIBUTIVE DYNAMIC DECISIONMAKING (DDD-III) 

1. Requirements 

A user friendly, easily modified, “low level” command and control simulator, the 
DDD-III paradigm models the Joint real-world environment. A wide range of commands 
and data strings are available to abstract the complex components and variables 
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associated with a Joint battle space. The DDD-III was developed to fulfilling the 
following needs: 

• Create a realistic” Joint environment within a computer simulation, 
abstraeting the various elements of Army, Navy, Air Foree and Marine 
warfare, found in the Joint Task Force environment, to an understandable 
computer representation. 

• Provide for the easy manipulation of key structural variables to allow 
testing of basic hypotheses dealing with structural change. 

• Avoid the need to build/require a technical domain expertise in test 
subjects, thereby allowing the experiment to be conducted on-site at NPS 
using available officers. 

• Create a simulator that would allow for ease of scenario design/change, 
data collection and data retrieval DDD-III provides a multi-player, 
real-time, model-based simulation enviro nm ent 

2. Environment 

The DDD-III has the ability to explicitly operationalize many of the relevant 
organizational dimensions within a Joint task force (JTF). There are three essential 
factors which make the DDD-III ideal for the tier-I experiments: 

• Joint warfare framework 
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• Mission structure - represented as tasks, linked together by time, space 
and/or precedence to provide a theater level mission for the organization to 
accomplish. 

• Force competition - used to “force” coordination between the DMS in 
setting priorities, allocating limited organic and non-organic resources as 
to achieve the overall mission objective. 

3. Core elements 

The DDD-III software gives the user the ability to modify dimensions of task, 
platform and organizational structure in order to test a specific hypothesis. These 
dimensions are the core elements of the paradigm. The dimensions are manipulated to 
study their interactions and to elicit possibly changes in organizational structure and 
response from a team. 


C. PHASE ONE EXPERIMENT 
1. Hypothesis 

The phase one hypothesis can be summarized effectively as follows: “An 
organization with a common functional commander is better for certain tasks than an 
organization without one.” 
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Goal 


The phase one experimental goals were twofold: 

• To test the interaction between task structure, organization structure, and 
components in a joint environment given a common operational picture 
across all levels of hierarchy. 

• To validate the DDD-III paradigm and the procedures of abstraction used 
by the scenario designer to develop the scenario specifics. 

3. Scenario 

The scenario chosen was representation of a “typical” future requirement for US 
forces, a Joint forces mission to capture a port and airfield which will allow for the 
introduction of follow-on forces. The assets available to the DMs represented force 
structure already in use in the real-world Joint environment. 

4. DDD Development 

One significant challenge was to model elements of the real-world into the DDD- 
III without extensive software modifications or complex co mmand s, consuming the 
scenario designers time and distracting from the goal of the simulation. 

a. Phase one issues 

Many imique applications of the generic DDD-III co mmands were 
developed in order to represent the Joint world as accurately as possible. The challenge 
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was to abstract elements of the real-world that did not fit the generic mold of a direct 
threat, such as geography and stand-off weapons. Major implementation and abstraction 
were discussed. 

b. Future issues 

While implementing the current scenario requirements, additional ideas 
for abstracting elements in the DDD-III were considered for future use. Some of these 
concepts have been developed while others are in the “idea” stage. The major concepts 
were reviewed and the possible changes to the DDD discussed. 

D. FUTURE EXPERIMENTS - PHASE TWO 

Although analysis of this experiment is not yet completed, initial indications are 
that the DDD-III provides the needed abilities for the modeling of the Joint warfare 
environment into a tier-I level experiment. The results of this experiment, coupled with 
modeling theory being developed separately, will form the basis for phase two. It is 
anticipated that these experiments will involve changing of organization structure, in 
response to changing task structure, during the simulation run. This phase is expected to 
be performed in late 1996. 

E. CONCLUSIONS 

The underlying DDD-III paradigm was found to be valid for tier-I experimentation 
- the DDD-III allows the scenario designer to easily manipulate and control the many 
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experimental dimensions. Additionally, the experiment fulfilled its two general purposes: 

• To test the interaction between task structure, organization structure, and 
components in a joint environment given a common operational picture 
across all levels of hierarchy. 

• To validate the DDD-III paradigm and the procediues of abstraction used 
by the scenario designer to develop the scenario specifics. 

Finally, this experiment provided much needed data and lessons learned to support the 
next experimental phase. 
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APPENDIX A. [DDD Scenario Generator Users Manual] 

1. INTRODUCTION 

2. GENERAL ITEMS 
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4. STATE INFORMATION 
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1. INTRODUCTION 

The 3rd-generation Distributed Dynamic Decisionmaking (DDD-III) paradigm was 
designed to meet the needs for empirical research in adaptive architectures for Joint 
Command and Control (C2). The DDD-III is implemented as a multi-player, real-time 
simulation that provides a team of decisionmakers with an air, sea and ground 
environment, a variety of task classes, and controllable platforms with subplatforms, 
sensors and weapons (resources). This flexible research paradigm provides the ability to 
conduct controlled experiments in a laboratory environment, using problems that are 
abstractions of the “real world”. 

The design of the DDD-III focuses on the dynamic/execution phase of the mission 
and allows for manipulation of key structural variables in task and organizational 
dimensions. The DDD-III has the ability to constrain and/or to manipulate 
orgamrational structures such as authority, information, communication, resource 
ownership, task assignment, etc. 

The scenario generator is the tool through which the scenario designer translates the 
mission requirements found in the “real-world” Joint military environment into DDD- 
specific constraints, defining the Joint warfare “game” world. The scenario generator 
assists the experimenter in preparing the many options and variables used to create the 
game. There are four major categories of variables available to the game planner to create 
the desired simulation: 

1) General information - including time, number of players, shape of land, etc. 

2) Platform and Task class information - defining both fiiendly and “hostile” 

forces. 

3) State Information - defining attributes, resources and game element sequencing. 

4) Maneuvering information - defining the actual movements of the tasks. 


2. GENERAL ITEMS 

The commands in this section define the structure and overall generic features of the 
scenario. These commands allow the scenario designer to create a “fi'amework” within 
which the Joint environment can be abstracted. The chain of command, number of 
decisionmakers, game duration and other structural elements are enumerated, as well as 
land, roads, boimdanes and other geographic features. Additional features can be added by 
tailomg task commands (found in section three) to represent fixed areas to be avoided by 
the simulation players. The default values of each parameter when applicable are listed 
within the command description. 

Decision Structure 

This command defines the number of decisionmakers present in the simulation. In 
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addition it identifies the command structure they are contained within, (in reference to the 
other decisionmakers) This allows the scenario designer to specify command structure, 
which affects authority/responsibility and asset control issues among decisionmakers. 

Only acyclic structures are supported in DDD-III. 

Format: decision structure ndm 

name(O) name(l)... name(ndm-l) 
cd(0) cd(l)... cd(ndm-l) 

# ndm : number of decisionmakers in the game. default=4 

# name(I) : alphanumeric string (up to 5 chars) for DMi's name. default='DMi' 

# cd(I) : the dm to whom DM#I reports (DM#I's boss). default=0 

constraint: cd(I) I, to assure that a decisionmaker will only have one “boss” (Acyclic 
structure) 

Example: decision structure 6 

CJTF GCC MEUl MEU2 CVBG ARG 
0 0 1 10 0 

Explanation: There are six decisionmakers defined. DM1 is assigned the name CJTF, 

DM2 is assigned the name GCC, etc. The command structure in this example is a three 
tiered hierarchy consisting of the CJTF as overall commander, with GCC, CVBG and ARG 
reporting to the CJTF. The two MEU’s are reporting to GCC. 

Simulation Time 

This command sets the scenario duration in seconds, thereby allowing the experiment 
designer to determine the maximum game time for each scenario run. The end game 
command can be used to stop the simulation if the decisionmaking team has fulfilled their 
objectives prior to reaching this preset simulation time. 

Format: simulation time ts 

# ts : floating number. Maximum time allowed in the game. default=600.0 
Example: simulation time 2400.0 

Explanation: The game will last a total of2400 seconds (40 minutes) 

Number of Tasks 

This command sets the total munber of tasks allowed during the simulation. A task is 
used by the scenario designer to represent enemy threats, mission objectives, fixed land 
objectives, etc. Each task must be further defined in the state and maneuver sections - if 
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not the scenario generator will automatically, randomly , create tasks to reach this preset 
number. (Which can significantly impact the scenario sequence) 

Format: numberof tasks n 

# n: integer number of tasks in the game, max=200, default=50 
Example: number_of tasks 140 

Explanation: A maximum of 140 individual tasks exist in this simulation. (Not all tasks 
may necessarily “arrive”. This depends on their arrival times and the simulation time) 

Simulation Scale 

This command defines the “size” of the playing area. The value specified will represent 
the length of each side of the display area in miles. (The units in the simulation be 
miles. Km, ft, etc, - as long as consistency is maintained throughout the scenario file 
specification) The display area will be overlaid by a ten by ten square grid to provide map 
coordinates. 

Format: simulation scale s 

# s : floating number. default=1.0 

Example: simulation scale 100.0 

Explanation: The playing area will be a 100 by 100 square mile grid area. (The XY grid 
used in the display is as follows: X coordinate begins fi’om 0 on the left side of the screen 
and goes to 100 on the right. The Y coordinate begins fi'om 0 on the top of the screen and 
goes to 100 on the bottom.) 

Number of Attributes 

This command sets the total number of attributes used to define the characteristics of the 
taste. E^h task attribute in the vector is assigned a unique name. The attribute value 
position in the vector is critical - later inputs or references to the attribute vector rely on the 
order of the numerical values to set the attribute characteristics, (ie: all attributes must be 
defined each time when referencing the attribute vector) The first two attributes in the 
vector are fixed in definition: attribute one = Value, is the value that the task is worth to the 
decisionmaker when properly accomplished. (It also represents the amount lost if not 
successfully attacked.) Attribute two = Time, is the duration assigned to the engagement 
when the task is prosecuted (actually attacked) by a platform. 

Format: number_of attributes natt 

name(l) name(2)... name(natt) 
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# natt : integer number up to 20. Default=3 

# name(I): string of up to 5 chars for attribute#rs name. Default='Attri' 

Example: number of attributes 10 

Value Time Air Sea Groun hold Mine tank Med enemy 

Explanation: A total of ten attributes are defined for the attribute vector. Each attribute is 
assigned a name: Value, Time, Air, Sea, etc, whose position in the vector is unique.. 

Number of Resources 

This command sets the total munber of resource categories that will be used to define the 
characteristics of the platforms. A platform is used by the scenario designer to represent 
fiiendly assets, such as aircraft, ships, ground units and fixed bases. Each platform will 
have a vector of resources where each element in the vector is assigned a unique name. 

The position of the resource value in the vector is critical - later inputs or references to the 
platform resource vector uses the order of the numerical values to set the resource 
characteristics, (i.e.: all resources must be defined when referencing the resource vector) 

Format: number_of resources nres 

name(l) name(2)... name(nres) 

# nres : integer number up to 20. default=3 

# name(I): string of up to 5 chars for resource#rs name. Default='Resi' 

Example: number_of resources 7 

air sea groimd hold mine tank Med 

Explanation: a total of seven resource categories are defined in the resources vector. Each 
resource is assigned a name; air, sea, groimd, etc., whose position in the vector is unique. 

Renewal Interval 

This command allows the user to preset a screen renewal interval in order to avoid 
processor overload, caused by the computers’ attempt to continuously update all platform 
and task positions to all screen displays. 

Format: renew interval t 

# t: floating number of seconds between clock and screen updates. Default=l .0 
Example: renew interval 0.5 

Explanation: The screens will be updated every half second, which will be sufficient in a 
basic simulation of six players - however, a more involved game that has a greater number 
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of players may require a longer refresh cycle, such as 2 seconds, depending on the CPU. 
Random Seed 

This command sets the random seed used in the simulation run. The random seed is 
applied to produce a sequence of pseudo random numbers that are used to generate task 
and platform information. For the same xsnnnn.dat file, different random seeds will 
produce different information elements on the tasks and platforms. This function can be 
used by the scenario designer to provide a randomness for the values of the attributes. 
(This randomness can be useful in defining the attributes of the neutral task-s to provide 
some diversity between scenario r uns ) 

Format: random seed r 

# r: positive integer number. Default=5 

Example: random seed 1 


Explanation: Provides a random seed value of 1 to the random noise generator 
Message Number 

This command sets the number of information channels each decisionmaker owns. A 
channel can hold only one message at a time. If all channels owned by a decisionmaker are 
filled with messages the decisionmaker cannot send out any messages until a channel is 
cleared. 

Format: message number n 

# n: positive integer number of communication channels available. Default=4 
Example: message number 4 

Example: Assigns a total of four message channels to each decisionmaker. 

Communications Epoch 

This command sets the time a commumcations channel is held for transferring a message. 
Unlike communications delay^ Which sets the time delay for a message to reach its 
destination afrgr being sent from the decisionmaker, communications epoch concerns the 
time Ae communications equipment itself is tied up during message transmission. This 
function can be used by the scenario designer to simulate the internal delays associated 
with routing a message to be released through your own command hierarchy. 

Format: comm epoch t 

a t. floating number of seconds a comm, channel is bus:y after sending a msg. 
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Default=6.0 

Example: comm epoch 6.0 

Explanation: Any commvmications channel used by the decisionmaker will be tied up for a 
period of six seconds following transmission. 


Communications Delay 

This command sets the time it takes for a communication message to reach its destination 
after initiation from the source decisionmaker. This command allows the scenario designer 
to accoxmt for the delays associated with message transmission in a global perspective 
(satellite delays, system busy signals, etc) 

Format: comm delay t 

# t: floating number of seconds it takes for a message to be received. Default=15.0 
Example: comm delay 5.0 

Explanation: Messages will be “delayed” for a period of five seconds before being 
displayed on the receiving decisionmakers terminal. 

Request Delay 

This command sets the time it takes for a resource request message to reach its destination. 
Functions similarly to the communications delay. This command can be used by the 
scenario designer to simulate the delay encoimtered when a request for assistance is sent to 
another command. A zero delay would mean instantaneous response. 

Format: request delay t 

# t: floating number of seconds it takes for a request to be received. Default=15.0 
Example: request delay 5.0 

Explanation: All resource request messages will be delayed a total of five seconds before 
being displayed on the destination terminal. 

Transfer Delay 

This command sets the time it takes for a transferred platform to reach its new owner after 
the initiator has completed the transfer command. This command can be used to simulate 
the time required for the chain of command to assign that unit to the new task force. 
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Format: transfer delay t 

# t: floating number of seconds it takes for a transfer to be received. Default=20.0 
Example: transfer delay 10.0 


Explanation: Platform transfers will be “delayed” a total often seconds before being 
available to the receiving decisionmaker. 


Attack Delay 

This command sets the default time it takes for a task to be destroyed once an attack has 
been initiated. Both the attacking platform (s) and the task are frozen for this period. This 
allows the scenario designer to simulate the use of assets in a real-world engagement, 
where engagements “remove” the asset from the order of battle for a period of time. 

Format: attack delay t 

# t: floating number of seconds an attack requires. 

NOTE: Since the 2nd attribute is the attack delay, this command sets the default for the 
2nd attribute. Default=15.0 

Example: attack delay 15.0 

Explanation: The default attack delay (freeze time) for any attack is set to fifteen seconds. 


Scramble Identification Number 

This command sets the task identification number scramble flag. Task numbers are 
specified in the maneuver section and are displayed as part of the task identification to the 
display screens. When set, this flag renumbers the display identifications. This command 
allows for the identification numbers of the contacts to change with each run of that 
specific scenario, which prevents the team from anticipating tasks based on their 
identification number. 

Format: scramble id d 

# d : integer number. Default=0 

# :0 — do not scramble the task id 

# : 1 “ scramble the task id 

Example: scramble id 0 
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Explanation: Task numbers are not scrambled and are as specified in the maneuver section. 
Communications Permission 

This command sets the communications structure for the decisionmakers within the 
simulation. If a communications link exists from decisionmaker i to j, DMi can 
request/send resources, information and action/intention messages to Dmj. This command 
is one way in which the scenario designer can augment the chain of command in the 
simulation, forcing DM’s to follow preset communications routes. 


Format: communication permission 

P(0,0) P(0,1) ... P(0,ndm-1) 

P(1,0) P(l,l) ... P(l,ndm-1) 

P(ndm-1,0) P(ndm-l,l)... P(ndm-1, ndm-1) 

# P(i j) = 1, DMi can communicate with DMj. (i.e. link exists from I to j) 

# =0, DMi can't communicate with DMj. 

# Default: all diagonal elements are 0, the rest are 1 


Example: communication permission 


0 

1 

1 

1 

1 

1 

1 

0 

1 

1 

1 

1 

0 

1 

0 

1 

1 

1 

0 

1 

1 

0 

1 

1 

1 

1 

1 

1 

0 

1 

1 

1 

1 

1 

1 

0 


Explanation: The matrix defines the communications links between DM’s. All 


decisionmakers can communicate with each other except for DM2 and DM3, who cannot 
communicate with DM0, and are therefore forced to pass all requests for assets and 
messages to DM0 through an alternate routing. In our specific example DM2 and DM3 
represented MEU’s, who were expected to communicate through the GCC to the CJTF. 
(See decision structure) 

Land Area 

This command sets the portion of the game area defined as land. Sea tasks/platforms 
carmot cross on to the land area, and groxmd tasks/platforms cannot cross into the sea area. 

Format: land area xl y 1 x2 y2 

# xl : Upper-left X-coordinate 

# yl : Upper-left Y-coordinate 

# x2 : Lower-right X-coordinate 
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# y2 : Lower-right Y-coordinate 

# Default=no land. 

Constraints: 0< xi < s; 0^ )d ^ s (s = simulation scale) 

Example: land area 0.00 40.00 30.00 100.00 

Explanation: The defined land area will be a rectangle 30 units wide and 60 units long, 
beginning in the lower left comer and extending upward into the game area display. 


Draw Line 

This command allows the user to draw lines of varying thickness and length. These lines 
can be used to mark areas, define roads and add geographic relief to the game area display. 
Multiple draw line commands can be issued. 

Format: draw line xl yl x2 y2 [width] 

# xl : Upper-left X-coordinate 

# yl : Upper-left Y-coordinate 

# x2 : Lower-right X-coordinate 

# yl : Lower-right Y-coordinate 

# width: (optional) Line width, in pixels. Default: 1 

# Default=no lines drawn. 

Example: draw line 5.00 95.00 5.00 75.00 2 


Explanation: TWs will draw a line, two pixels wide, from xy grid (5,95) (upper left comer) 
to xy grid location (5,75). This line will appear as a straight vertical line 20 units long. 

Draw Rectangle 

This command allows the user to draw rectangles of arbitrary sizes in the game display 
area. This command can be used much like the draw line command to demark geographic 
areas, such as towns, etc., as needed in the playing area. 

Format: draw rectangle x y w h [width] 

# X : Upper-left X-coordinate 

# y : Upper-left Y-coordinate 

# w : Width 

# h : Height 

# width : (optional) Line width, in pixels. Default: 1 

# Default=no rectangles drawn. 
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Example: draw rectangle 27.00 49.50 2.50 4.00 

Explanation: This will draw a rectangle 2.5 units wide and 4 units long, using a 1 pixel 
wide line, with the upper left comer of the rectangle located at xy grid position (27,49.5). 

Draw Circle 

This command allows the user to draw arbitrary circles in the game area display. This 
command can be used much like the draw line and draw rectangle command to demark 
geographic areas, such as landing zones, as needed in the playing area. 


Format: draw circle x y radius 

# X : Center X-coordinate 

# y : Center Y-coordinate 

# radius : Radius of circle 

# width : Line width, in pixels. Default: 1 

# Default=no circles drawn. 

Example: draw circle 10.0 50.0 5.0 

Explanation: This will draw a circle with a radius of 5 units, using a 1 pixel wide line, 
centered at xy grid position (10,50). 

Penetration Number 

This command specifies the total number of penetration zones contained in the game area 
display, and must come before the penetration zones are defined. (See penetration zone 
command for an explanation of the penetration zone use) 

Format: penetration number npen 

# npen: Number of penetration zones. Default is npen=l, a circular penetration zone 

that will be sensitive to all task classes. If the user fails to give the location of 
the zones they will be clustered at the center of the display area at (s/2, s/2). 

Example: penetration number 7 

Explanation: Defines a total of seven penetration zones in the game area display. 
Penetration Zone 

This command defines the actual penetration zones, either rectang ul ar or circular. The 
zones are numbered starting from 0. The zones will appear in the display as a thick red 
bordered area. Penetration zones represent areas that are sensitive to various task classes. 
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When a zone is penetrated by these tasks the team losses points. This allows the scenario 
designer to create an area, vice a specific point, of vulnerability that must be protected - 
i.e.: the area around a carrier in which the enemy has the capability (and desire) to strike 
with cruise missiles. 

Format one: penetration zone rectangle ip x y w h 

# ip: number of the penetration zone 

# x: floating number, the x coordinate of upper left comer of the penetration zone. 

-# y: floating number, the y coordinate of upper left comer of the penetration zone. 

# w: floating number, the width of the penetration zone. 

# h: floating number, the height ofthe penetration zone. 

Format two: penetration zone circle ip x y r 

# ip: number of the penetration zone 

# x: floating number, the x coordinate of center of the penetration zone. 

# y: floating number, the y coordinate of center of the penetration zone. 

# r: floating number, the radius of the penetration zone. 

# Default: penetration zone circle, in the center of the screen with radius 

0.2*(simulation scale) 

Example: penetration zone rectangle 0 26.50 70.00 4.00 6.00 
penetration zone circle 1 25.00 45.00 5.00 

Explanation: Assuming npen=2, the first command will create a rectangular penetration 
zone, with id=0,4 units wide and 6 units long with the upper left comer located at xy grid 
position (26.5,70). The second command will create a circular penetration zone, with id=l, 
of 5 unite radius with the center located at xy grid location (25,45). (The individual task 
sensitivity to these zones is defined in the task penetration command) 

3. CLASS INFORMATION 

The platform/task class information specified in this section sets the common features 
of the platforms and tasks, which are in turn used to generate specific platform/task state 
information. 

3.1 platform class information 

Platform Classes 

This command sets the number of unique classes of platforms that exist in the scenario. 

For the purpose of platform class number both platforms (parent) and subplatforms (child) 
are counted equally. (The actual specification of platform/subplatform relationship is set 
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using the platform subplatform command) 

Fonnat: platform classes npc 

# npc : integer number up to 35. Default=6 

Example: platform classes 26 

Explanation; A total of 26 classes are available for use in the scenario (for both platforms 
and subplatforms combined) 

Platform General 

This command sets the parameters for each specific platform class. These initial 
specifications define the platform and form the basis for platform uniqueness. The values 
of these parameters and their various combinations provide a broad range of options to the 
scenario designer to create models of real-world assets. (Air, sea and ground) 

Format: platform general id type class mv xfr 
reu ret e r d 

# id: integer, xxniquely identifying this platform class, starting fi-om 0. 

# type: single character A, S, G for Air, Sea, or Ground vehicles. default=A' 

# class: string of up to 3 characters which gives a “name” to this class of platforms. 

default='Pid' (where id = id# above) 

# mv: maximum velocity of platforms of this class. Default=0.0070*simu_scale 

# xfi*: transferability flag: 

= 0 platforms of this class cannot be transferred. 

= 1 platforms of this class be transferred. 

Default=l 

The following variables refer to the platform class when used as a subplatform. They 
are NOT optional parameters. 

# ret: return ability flag: 

= 0 subplatforms of this class cannot be returned after being launched 
= 1 subplatforms of this class can be returned after being launched. Default=l. 

# reu: reusable flag: 

= 0 subplatforms of this class cannot be reused once they are used in attack. 

= 1 subplatforms of this class can be reused for multiple attacks 
Default=l. 

# e: endurance, floating number of seconds that the subplatform is available for use, 

once launched. Default=60.0 

# r: refuel time, floating number of seconds. The time between the return of an asset 

and its availability for relaunch. Default=5.0 

# d: launch delay, floating number of seconds. Default=20.0. 
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Example: platform general 0 AVF 0.9900 1 

1 1 3000.00 3.00 15.00 

Explanation: This defines a platform class with an id=0, as an Air type. Any platform of 
this class will be named VF, and have a maximum velocity of .99 (1.0 equals one mile per 
second). Any such platform is transferable, returnable and reusable, with a life duration of 
3000 seconds (50 minutes), a refueling time of 3 seconds and a launch delay of 15 seconds. 
Transferability indicates that the platform can be given to another DM. Retumability 
indicates that the platform can go back to its original parent. Reusability indicates that the 
platform will be available for use again after an attack. 


Platform Resource 

This command assigns the default values of the resource vector associated with that class 
of platform. These values will be carried through to each platform of that class. This 
allows the scenario designer to “arm” the platforms with various “weapons”, giving the 
platform the ability to engage tasks. 

Format: platform resource id w(l) w(2) ... w(nres) 

# id : integer number, identification of the platform class. 

#w(I): integer number, the amount ofresource of category I. Default w(I)=l 

Example: platform resource 0 50 50 50 50 50 50 50 

Explanation: Each element in the resource vector of platforms of class 0 is assigned a 
value of 50. These resources, defined in number_ of resources, can represent the 
platform’s ability to engage air targets, its ability to clear minefields, etc. 

Platform Range 

This command sets the range of the sensors contained on each platform. Each platform has 
three types of notional sensors which provide mformation on air, sea and ground tasks, 
respectfiilly. Associated with each sensor are five ranges, each displayed by a separate ring 
centered on the platform. If a task is within the outer most range ring it can be seen 
(detected) by the platform. If the task is within the next range ring the various attributes of 
the task will be read (measurement), although the values may be masked/corrupted by 
noise. If the task is within the third range ring the task class becomes known automatically 
(identification). The fourth range ring denotes the range in which the task can be attacked 
by the platform. The last range ring indicates the range at which the platform can be 
attacked by the task. By varying these ranges the scenario designer can model various 
abilities and limitations of the platform class. 


112 



6/20/96 


Scenario Generator Users Manual 


Format: platform range id 

r(l,l) r(l,2) r(l,3) r(l,4) r(l,5) #Air = type 1 

r(2,l) r(2,2) r(2,3) r(2,4) r(2,5) #Sea= type 2 

r(3,l) r(3,2) r(3,3) r(3»4) r(3,5) #Ground = type 3 

# id: integer number uniquely identifying the platform class. 

# r(ij): positive floating number. 

# r(i,l) = detection range of platforms of class id on task type I 

# r(i,2) = measurement range of platforms of class id on task type 1 

# r(i,3) = identification range of platforms of class id on task type 1 

# r(i,4) = attack range of platforms of class id on task type I 

# r(i,5) = 'be-attacked' range of platforms of class id on task type I 

# Default r(ij)=(.3-.05i)*simu_scale 

Example: platform range 0 

30.00 25.00 20.00 10.00 3.0 

20.00 15.00 10.00 5.00 2.0 

10.00 10.00 8.00 7.00 1.0 

Explanation: Platforms of class 0 have been assigned values for air, sea and ground ranges. 
In this example, for air the detection range is set to 30, the measurement range is set to 25, 
and the identification range is set to 20. The range at which the platform can attack an air 
task is set at 10 while the range at which the platform is vulnerable to attack by an air task 
is set to 2. (The sea and ground ranges are different than the air.) 

Platform Accuracy 

This command sets the “noise” applied to the attribute values that are measured when tasks 
are within the platforms’ measurement range. This noise allows die simulation designer to 
more closely model the real-world environment by introducing doubt into the attribute 
readings, which could be caused by a variety of elements, such as atmospheric conditions 
or the stealth characteristics of a target. 

Format: platform accuracy id 

e(l,l)e(l,2)... e(l,natt) 
e(2,l) e(2,2)... e(2,natt) 
e(3,l) e(3,2)... e(3,natt) 

# id: integer number uniquely identifying the platform class. 

# e(i j): Positive floating number which gives the standard deviation of the (Gaussian) 

measurement noise for sensor of type I when measuring task attribute j. 

Default: e(i j)=0.00, i.e. no noise. 
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NOTE: if e(i j) < 0.0 then that sensor makes NO measnrement of that attribute. 

Example: platform accuracy 0 

0.00 0.00 0.15 0.00 0.00 0.00 0.00 0.00 0.00 -1.00 

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 - 1.00 

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 - 1.00 

Explanation: In this case the sensor noise is zero for almost all attributes and sensor types. 
However, the third attribute of the air sensor has measurement noise with a standard 
deviation .15. The standard deviation of last attribute in all sensors (air, sea and ground) is 
set to a negative one, which will result in its not being measured by any of the sensors, of 
platform class 0. 


Platform Subplatform 

Subplatforms are previously defined platforms that reside on another platform (example: 
aircraft on a carrier, troops on a helicopter). Platforms of a given class may contain a 
number of subplatforms fi'om different platform classes. There are several guidelines that 
apply to the subplatform concept: 

1) The same class of subplatform (child) can reside on many platfo rms (parent). 

2) All subplatforms of a given class are identical, independent of the platform they 
reside within. 

3) The “depth” of the nesting structure is defined by the designer and is not limited 

by the software - however, loops are not allowed, (i.e.: Bp A) 

This command sets several specifications. 

1) The number of subplatform classes that a specific platform class has. 

2) The name of the subplatform classes. 

3) How many of each subplatform is contained onboard the platform. 

4) Who owns the various subplatforms when they are launched. 

NOTE: The default is no subplatforms present on platforms 

Format: platform subplatform id num 

sub_class(l) sub_class(2)... sub_class(num) 

^(0 n(2) ... n(num) 

owner(l) owner(2) ... owner(num) 

# id: integer number, giving the unique identification of the platform class. 

# num: integer number, indicates the number of subplatform classes that this platform 

class has, max=7 NOTE: The maximum number of subplatforms that can be 
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'on-screen' at any one time is 100. 

# sub_class(I): the name of the subplatform class. This name must be one of the class 

given in an earlier platform general command. 

NOTE: The platform and subplatform classes must be defined (via the platform general 
command) BEFORE the definition of their nesting structure. 

# n(I): the number of individual subplatforms of class 'sub_class(I)' on board this 

platform class. 

# owner(I): the number of the decisionmaker who will own the individual subplatforms 

of class 'sub_class(I)' when they are launched. 

NOTE: If owner(I)= -1 these subplatforms will be owned by whomever “owns” the parent 
platform - e.g. this gives the designer the ability to model self defense weapons. 


Example: platform subplatform 15 3 


VF 

VA 

H60 

3 

2 

1 

4 

0 

0 


Explanation: Each platform of class 15 (parent) will have three subplatform classes 
(children) onboard. The three subplatform classes are VF, quantity 3, owned by DM4; VA, 
quantity 2, owned by DM0; and H60, quantity 1, owned by DM0. (See previous platform 
general command for definition of class VF.) 


3.2 Task class information 

Task Class Number 

This command sets the total number of task classes available for the scenario. 

Format: task classes ntc 

# ntc : integer number, with the maximum 50, Default= 6 
Example: task classes 24 

Explanation: The total number of task classes is set to 24 
Task General 

This command sets the parameters for a specific task class. These initial specifications 
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clearly define the task and form the basis for task uniqueness. The values of each 
parameter and their various combinations provide a broad range of options for the scenario 
designer to create models of real-world threats. These values are used each time a task of 
this class is created. 

Format: task general id type class mv p threat flg [iconjfile] 

# id: integer uniquely identifying this task class, starts from 0. 

# type: single character A, S, G for Air, Sea or Ground tasks. Default = ‘A’ 

# class: string of up to 3 characters which gives a name to this class of tasks. 

Default= class#0='A', class#l='B' etc. 

# mv: maximum velocity of this class of tasks. Default=0.0040*simu_scale 

# p: appearance probability of this class of task. Default p=l/ntc, where ntc is 

total number of task classes. 

# threat_flg: indicates whether the task is a threat or a neutral. Default=l 

= 0 task is a neutral 

= 1 task is a threat to the penetration zones specified in task penetration command. 
= 2 task is a threat to specified penetrations zones and also to platfo rms ^ wi thin a 
radius Ri5 (specified m platform range) where the platform and task are both 
of type I. 

— 3 task is a threat to specified penetrations zones and also to platforms of any type 
within a radius Ri5 (specified in the platform range command) where the task 
is of type I. 

= 9 task is a 'job' to do. 

# icon_file: (optional) The name of an X bitmap icon file located in ~/usr/icon 

Example: task general 0 G HL 0.0 0.0424 9 hill.icon 

Explanation: This statement defines the task of “taking the hill”. Tasks of this class have 
id=0, are of type ground, and named HL. The maximum velocity is set to zero. The threat 
flag is 9, which indicates that this task represents a job or mission to be performed. The 
icon used to portray such tasks in the game will be hilhicon, which overrides the default 
icon file for standard ground tasks. 

Task Mean 

This command sets the default values for the attribute vector. Unless overridden latter in 
the task attributes portion of the scenario generator all tasks of the same task class will 
have these mean values assigned to their attribute vector. 

Format: task mean id a(l) a(2) ... a(natt) 

# id: integer number uniquely identifying the task class. 

# a(I): positive floating number, mean value of the attributes I of the task class. 
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Default a(I)=I 

Example: task mean 0 10.00 20.00 0.00 0.00 5.00 0.00 0.00 0.00 0.00 1.00 

Explanation: Task Class number zero will have the above values assigned as the default 
values for the attribute vector. 

Task Sigma 

This command sets the standard deviation of the tasks’ attribute vector. This allows the 
simulation designer to “smear” the attribute values that are associated with a specific task. 
Unlike the platform accuracy command, which affects the sensors of a specific platform 
class, this command affects the actual task values, independent of the platform, so the 
variation in attribute values is applied to all platforms and all sensors that can “see” this 
task class. 

Format: task sigma id sigma(l) sigma(2) ... sigma(natt) 

# id: integer number, identification of the task class. 

# sigma(I): the value of the standard deviation on attribute I. Default sigma(I)=0.00 

Example: task sigma 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 

Explanation: Task of class 0 will have their attribute vector generated without additional 
values being added or subtracted to the mean attribute vector. (No sigma applied) 

Task Mapping 

This command specifies a linear mapping fi-om the attributes of a task class to the resource 
requirements for a successful attack on that class . The structure of the mapping for the 
resource vector is: r =Aa+b, which allows for an assignment of attribute values to resource 
values zmd for the addition of a constant. This allows the simulation designer to control the 
resource match up between tasks and platforms, which enables a representation of the 
differences in firepower and engagibility found in the real-world. 

Format: task mapping id 

A(l,l) A(l,2) ... A(l,natt) B(l) 

A(2,l) A(2,2) ... A(2,natt) B(2) 

A(nres,l) A(nres,2)... A(nres,natt) B(nres) 

# id: integer number, identifying the task class. 

# A(i j): Floating number, which indicates Ihe mapping from task attributes to 

resources required to attack a task of this class. Default: A: ith row = 0, 
EXCEPT element A(1,1+2) = 1; if (I+2<=nattr) 

#B: all B(I) = 0 
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Example: task mapping 0 

0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 1.00 

Explanation. This matrix directly maps the attributes into required resources for tasks of 
class 0. The first line assigns resource one to attribute three, the second line assigns 
resource two to attribute four, etc. The 1.0 in the B vector of resource seven indicates that 
in addition to the one-to-one assignment from attributes to resources, one more unit of 
resource seven is needed. 

Task View 

This command determines the team information structure for the detection of a specific 
^^ ^^ g^ass by any platform owned by a specific DM. This allows the simulation designer to 
tailor the tactical picture of the DM’s to more closely resemble the real-world. (Various 
degrees of Global awareness” can be modeled via this command) 

Format: task view id v(0) v(l) v(2)... v(ndm-l) 

# id: integer number, uniquely identifying the task class. 

# v(I). integer number which specifies the degree to which the decisionmaker Dmi 

can observe this class of tasks. Its value can be 0,1 or 2. Default v(I)=2 

— 0: DMi cannot see a task of this class unless the task happens to be wi thin the 

detection range of at least one of his own sensors. 

— 1: DMi can see a task of this class if the task is detected by any of the sensors bn 

platforms owned by other DMS. 

— 2. pMi can see a task of this class and get attribute/class information if the tgak 

is within the measurement/identification ranges of any of the sensors on 
platforms owned by other DMS. 

Example: task view 02 2 2 2 2 2 

Explanation: Task Class number zero can be seen by all Decisionmakers. Attribute values 
of the task can be seen by all DM’s if it is within the sensor range of any platform owned 
by any decisionmaker. 

Task Stealth 

This optional command resets the detection, measurement, identification, attack and be- 
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attack ranges for a specific task class vis-a-vis a specific platform class. (Overrides default 
values.) This allows the scenario designer to tailor ranges down to an individual threat or 
mission, which can be used to create the possibility of a late detection or non-detection of a 
unique threat. (Example: ground or sea mines) 

Format: task stealth idl id2 [sensor(l) sensor(2) sensor(3) attack(l) attack(2) ] 

# idl: integer number, identifying the task class. 

# id2: integer number, identifying the platform class. 

# sensor(I): floating point numbers: 

1=1: overrides sensor detection range r(j,l) of platforms of class id2 when 
encountering tasks of class idl (that are of type j) 

1=2: overrides sensor measurement range r(j,2) of platforms of class id2 when 
encountering tasks of class idl (that are of type j) 

1=3: overrides sensor identification range r(j,3) of platforms of class id2 when 
encountering tasks of class idl (that are of type j) 

Default: values r(j,i) as specified in platform range command -- EXCEPT if threat_flg = 2 
or 3, in which case default values = r(j,5) 

# attack(I): floating point numbers: 

1=1: overrides associated attack range r(j,4) of platforms of class id2 when 
attacking tasks of class idl (that are of type j). Default: value = r(j,4), 
EXCEPT if threat flg = 2, in which case default value = 0.0 
1=2: overrides associated be-attacked range r(j,5) of platforms of class id2 when 
encountering tasks of class idl (that are of type j). Default: value = r(j,5) for 
all values of threat flag. 

Example: task stealth 0 0 100.00 90.00 80.00 20.00 0.00 
task stealth 0 1 40.00 30.00 20.00 5.00 2.00 

Explanation: Task class 0 has been assigned stealth values vis-a-vis platform class zero 
and one. In this example, if we assume that task class 0 is of type air, then the new ranges 
will apply to the Air ranges of the platforms specified. Line one sets the ranges for 
task/platform 0/1 pairings at 100 for detection, 90 for measurement, 80 for identification, 
20 for attack and 0 for be-attack, which will prevent the task from being able to attack the 
platform. These new values will override the default value of the Air range for platforms 
zero and one, previously specified platform range against tiiis task class. All other ranges. 
Sea and Groimd, will retain the default values specified in platform range command. 


Task Expertise (Not used in the current version of DDD - default values are hard-coded.) 
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This command sets the level of expertise which the decisionmaker has to interpret the 
attribute measurements. This allows the scenario designer to “level the playing field”; 
which has a variety of uses, such as adjusting for the vaiying professional backgrounds of 
the decisionmakers, which may affect team performance. 

Format: task observe expertise id 

0(0,1) 0(0,2) ... O(0,natt-1) 

0(1,1) 0(1,2) ... 0(l,natt-l) 

0(ndm-l,l) 0(ndm-l,natt-l)... 0 (ndm-l 4 iatt-l) 

# id: integer number, specifying the task class. 

^ floating number to indicate the relative observation expertise for DMi on 
attribute j for the tasks of the specified class, 0(ij) must be fi'om 0.1 to 1, 
Default 0(ij) =1.0 

Example: Task observe expertise 1 
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Explanation: In this example all DM’s have the same abilities to observe all task 
attributes. 

Task Destroy (Not used in the current version of DDD - default values are hard coded.) 
This command sets the ability of the decisionmaker to destroy the specific task class. Like 
task expertise, this command allows the user to “level the playing field” if the professional 
backgrounds of the decisionmakers is such that a wide diversity of playing skills is 
expected. 

Format: task destroy expertise id d(0) d(l)d(2) ... d(ndm-l) 

# id: integer number, identifying the task class. 

# d(I): floating number which indicates the degree of expertise DMi has in attacking 

this class of tasks. It can take on value fi-om 0 to 1, Default d(I)=l .0 

Example: task destroy expertise 1 1 1 1 1 1 .5 

Explanation. In this example, all Dm’s have the same ability to destroy task number 1 
with the exception of DM5, who has a “handicap of 50% in his ability to destroy the task 
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Task Attack 

This command sets the ability of various decisionmakers to attack tasks of a given class. 
This allows the scenario designer to control who can attack a given task class, which can 
be used to highlight command structure differences as well as to control competition for 
assets needed for the attack(s).. 

Format: task attack id DMresp at(0) at(l) at(2)... at(ndm-l) 

# id: integer number, specifying the task class. 

# DMresp: DM responsible for this class of tasks. Default=0 

# at(I): integer flag which indicates whether DMi is (or can be) assigned to attack tasks 

of this class. Default at(I)=l 
= 0, DMi is not assigned to attack the tasks. 

= 1, DMi is assigned to attack the tasks. 

Example: task attack 12111111 

Explanation: In this example, the responsibility for tasks of class 1 is assigned to DM2, 
but all DM’s have the ability to attack tasks of this class when identified. 

T9§k Pen g Mtion 

This command sets the sensitivity of the penetration zones defined earlier in penetration 
zones to the various task classes. This allows the scenario designer to create areas that 
must be defended from attack by specific task classes. 

Format: task penetration id p(0) p(l) ...p(npen-l) 

# id : The task class to which this command refers. 

# npen: The number of penetration zones defined by penetration number earlier, 

# p(I) : = 1 means class#id is capable of doing damage to penetration zone#I. 

# =0 means class#id cannot do damage to penetration zone#I. 

Default p(I)=l 

Example: task penetration 0 0000000 
task penetration 1 0000110 

Explanation: In line one the task class 0 cannot do damage to any of the seven penetration 
zones defined. In line two the task number 1 can do damage to penetration zones four and 
five. 


4. STATE INFORMATION 

The conunands listed in this section provide the user the ability to specify parameters 
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of individual platforms and tasks. If no specific state information is provided the scenario 
generator will create values derived from the values contained in the previous class 
commands. 

Platform Number 

This command specifies the total number of individual platforms used in the simulation. 

Format: platform number nplat 

# nplat: integer number, with the maximu m 99. Default 6 

Example: platform number 11 . 

Explanation: There are a total of eleven platforms in this simulation. 

Platform Definition 

This command allows the user to specify each individual platform used in the simulation, 
as well as which decisionmaker has initial control over the platform and where it is located 
at clock start. This command allows the scenario designer to specify order of battle for 
own forces. 

Format: platform definition id class dm x y 

# id: integer number between 0 to 100, giving a unique platform id. 

# class: string of up to 3 chars giving the unique name of the class this platform 

belongs to as described in 'platform general' command, Default=name of class 
#0 as described in 'platform general' c ommand 
#dm: the DM this platform belongs to initially. Default=l 
#x: X coordinate of the platform initial position. 

# y: y coordinate of the platform initial position. 

Default (x, y) coordinates are generated randomly 
Example: platform definition 0 CVN 4 70.00 15.00 

Explanation: This places platform number 000 at xy grid location (70,15). It is a CVN, 
and is owned initially by DM4. 

NOTE: It is important that the designer provide a definition for the total number of 
platforms specified 'm platform number, otherwise the scenario generator will create default 
platforms (of class 0) to make up the total number. 

Task Definition 

This command allows the user to specify class and initial responsibility for each 
individually numbered task to be used in the simulation, as well as the tasks’ priority to the 
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decisionmaker who is responsible for this task. This allows the scenario designer to 
specify class and responsibility for each individual task, uniquely identifying each “target” 
or “mission” presented to the team. 

Format: task definition id classmun iDM priority 

# id: integer number between 200 and 399 giving a unique id to the task. 

# classnum: the class number to which this task belongs. Default: generated per 

probabilities given in 'task general' command 

# iDM: the DM who is responsible for this task, Default=0 

# priority: priority of this task (an integer 0,1,2, or 3), Default=0 

Example: task definition 200 21 1 0 

Explanation: Task number 200, task class 21, is the responsibility of decisionmaker one, 
and has a (initial) priority of zero. 

Task Attributes 

This command can set the attribute values for an individual task specified in the 
simulation. This allows the scenario designer to specify each task uniquely. 

Format: task attributes id 

at(l) at(2)... at(natt) 

# id: integer number from 200 to 399, giving an unique id to the task. 

# at(I): positive floating number, attributes of this task. Defaults are generated 

randomly by task class according to values described in the task mean and task 
sigma commands. 

Example: task attributes 200 

02.0 10.0 00.0 00.0 20.0 00.0 00.0 00.0 00.0 00.0 

Explanation: In this example the task attributes are set for task number 200, overriding 
the initially defined default values. Each value above will be assigned to the appropriate 
position in the attribute vector. 

Task Resource 

This command sets the amount of resources required to properly engage the task (and 
receive full point values - engaging task with less than the required amount will result in 
“partial credit”) This overrides any default values previously defined. This allows the 
scenario designer to further tailor the properties of individrial tasks to platforms. 

Format: task resource id 
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res(l) res(2)... res(nattr) 

# id: integer number from 200 to 399, giving a unique id to the task. 

# res(I): positive floating number, resources required to prosecute the task. Defaults 
are generated from task attributes according to the procedure described in task 

mapping. 

Example: task resources 200 
0 0 20 0 0 0 0 

Explanation: In this example task 200 will require platfonn(s) with resources of at least 
res(3)=20 in order for it to be properly engaged. 

Task Prerequi.sites 

This command sets an “order” in which selected tasks must be prosecuted. This allows the 
scenario designer to cause the team to plan courses of action and mission priorities. 


Format: task prerequisites id num pr(l) pr(2)... pr(num) 

# id: integer number from 200 to 399, giving a unique id to the task. 

# num: integer number of prerequisite tasks that this task has 

# pr(l): the task number of a prerequisite for this class 

NOTE: prerequisites must have lower task number to avoid cycles [i.e. pr(I) < id ] 
Default=task has no prerequisites (num=0) 

Example: task prerequisites 310 3 236 237 238 

Explanation: In this example task 310 has three prerequisites that must be accomplished 
prior to engagement. If tasks 236,237, and 238 are not completed or have not disappeared 
(not necessarily in any particular order) the simulation will not allow an attack on tj^gk 310. 

Task Bias 

This command is used to introduce a bias, or offset, in the measurements of a given tasks’ 
attributes. The bias will be reduced to 0 linearly when the task is within attack range of the 
platform whose sensors are measuring the attributes. 

Format: task bias id 

b(l) b(2) ...b(nattr) 

# id: integer number from 200 to 399, giving an unique id to the task. 

# b(I): floating point number, bias in task #id when reading attribute #1. 

Default b(I)=0.00 
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Example: task bias 211 

0.0 0.0 1.0 1.0 - 2.0 10.0 1.0 0.0 0.0 0.0 

Explanation: Task 211, when measured, will have a bias applied, with the above values 
added or subtracted to its attribute vector. 

Task Spawn 

This commands sets a parent/child relationship for tasks. As the “parent” task is either 
engaged or destroyed a “child” task will then appear. This allows the scenario designer to 
include a measure of mission “growth” in his initial planning of the scenario. 

Format: task spawn id num type sid(l) ... sid(5) 
sid(6) ... sid(lO) 
sid(num-4)... sid(num) 

# id: integer id of 'spawner' task for which new tasks will be spawned. 

# num: integer number of tasks to be spawned. 

# type: character A or D denoting a task Attack or task Disappear event. 

# sid(I): integer ids of'spawned' tasks. 

NOTE: I) 0 < num < n, where n is specified via number_of tasks command. 

ii) a task can be both spawned and a spawner (ie, recursive), 
however, a task cannot be spawned by more than one spawner. 

iii) to prevent spawning cycles, ie, X spawns Y spawns X, we require id 
< sid(I), I = l..num. 

iv) at most 5 spawned task ids specified per line, and, for num > 5, only 
last line can have <= 5 task ids specified. 


Example: task spawn 286 1 A 289 

Explanation: In this example task 286, when attacked, will spawn task 289 
Task Remove 

This command inhibits arrival of future tasks depending on either the attack or 
disappearance of a given task. This can be used by the scenario designer to “anticipate” 
paths that may or may not be followed by the DM’s during the simulation. 

Format: task remove id num type did(l) ... did(5) 

did(6) ... did(10) 
did(num-4)... did(num) 
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# id: integer id of'remover' task for which future tasks will be removed. 

# num: integer number of tasks to be removed. 

# type: character A or D denoting a task Attack or task Disappear event. 

# did(I): integer ids of'removed' tasks. 

NOTE: I) 0 < num < n, where n is specified via number_of tasks co mmand 

ii) a task can be both removed and a remover (ie, recursive), moreover, 
a task can be removed by more than one remover. 

iii) at most 5 removed task ids specified per line, and, for n um > 5, only 
last line can have <= 5 task ids specified. 

Example: task remove 2114 A 234 235 236 256 

Explanation: In this example the attacking of task 211 will prevent 4 new tasks fi'om 
entering the scenario. This particular example was an artillery unit, in which by attacking 
the launcher no further rounds will be fired at friendly units. 

Game End 

This command allows the scenario designer to specify the mission completion point, in 
terms of attacking a specific task, which may occur before the time specified in game 
duration. 

Format: game end id time 

# id: game will gracefully end after the task number id has been attacked. 

# time: float delay time to wait before ending the game. Default: id=399, time=5.0. 

Example: game end 390 5.00 

Explanation: In this example the scenario run will terminate 5 seconds after an attack on 
task 390 completes. 


5. MANEUVER INFORMATION 

Maneuvers describe the track of a task, which includes turning points, velocity and the 
life span . For each task the scenario generator allows the user to enter up to five 
maneuver segments. The first element of the maneuver command defines the starting point 
for the task, the last element defines the ending point. The commands between the start 
and end point fall into two categories - ordinary and staying maneuvers. An ordinary 
maneuver moves the task between a starting point and a destination point at the designated 
velocity. A staying maneuver designates a staying period at the given position. The 
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velocity tised in this command is a relative velocity with a range from 0 (no velocity) to 1 
(maximum velocity as specified in task class information). 

Format: maneuver definition id time 
flag(l) x(l) y(l) v(l) 
flag(2) x(2) y(2) v(2) 
flag(m) x(m) y(m) v(m) 

# id: integer number uniquely specifying this task. 

# time: floating number specifying the task arrival time. If this number is omitted, a 
randomly generated arrival time will be assigned to the task. 

# flag(I): one character to indicate the type of the maneuver. 

# =m ordinary maneuver 

# =s maneuver of staying at a point 

# =e ending maneuver 

# v(I): relative velocity (0<vi<=l)., If flagi=s, then vi is the task's staying time 
rather than its velocity. 

# x(I),y(I): coordinates . 

Default: straight line maneuvers automatically generated, starting on a circle of radius 
= (simulation scale)/2 and ending in the center of the screen. 

Example: maneuver definition 200 1.00 
s 18.00 89.00 3600.00 
e 18.00 89.00 0.00 

Explanation: In this example task 200 will appear at time 1.0 on the scenario clock. It will 
appear at XY grid coordinates (18, 89) and remain stationary for a period of 3600 seconds, 
then disappear. 

Example: maneuver definition 21 60.00 
m 00.00 00.00 0.90 
m 30.00 40.00 0.80 
e 60.00 60.00 0.00 

Explanation: In this example task 201 will appear at time 60.0 on the scenario clock. It 
will appear at XY grid coordinates (00,00) and proceed to grid coordinates (30,40) with a 
speed of .9 times the default maximum speed of the task class (defined in task definition). 
Upon reaching the coordinates (30,40) the task will slow to .8 of maximum and turn 
towards the final grid coordinates of (60,60), where upon reaching them the task will 
disappeared. 
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6. SETTING UP AN EXPERIMENTAL SPECIFICATION FILE 

The procedure for generating the required files following scenario development is rather 
straight forward. In order to imderstand how the scenario generator turns the designed 
parameters into a scenario the file structure must be review. 

6.1 Scenario files 

There are two scenario data files that are used to set up the experimental enviro nm ent' the 
experiment specification file (x5) and the listing file (Is). 

6.1.1 Experiment specification file 

The xs file is the input file to the scenario generator, which contains all designer specified 
commands and values reviewed in the above sections. The file name is xsnnm.dat, where 
stands for experiment specification and the nnnn represents a four digit string used to 
identify the specific scenario. Each xs file contains information for one scenario - for each 
additional scenario multiple xsnnnn.dat files are required. The xsnnnn.dat file is used to 
describe the scenario parameters to the scenario generator. The file is written in 
experimental specification language (xsl) developed to provide users a fiiendly interface. 
There are several very basic restrictions regarding the writing of the xs file: 

• Blank lines are not allowed - use # as a separator between lines 

• Command keywords must be a string of lower case characters 

• The end of the class information block must include a flag: end_of_class_info 
The flag is used by the scenario generator as a control signal. 

• Vectors and matrixes dimensions and sizes must match the limits specified either 
by the designer or the default value. Missing or extra data will cause generator 
errors. 

• The order of the commands is important. The precedence outlined in the previous 
sections must be followed. 

• Co^ents may be used, however, the line must start with a #, which makes the 
entire line a comment line. 

6.1.2 Listing file (Is^ 

The Is file is the output file of the scenario generator, which is used in the controller 
window to run the simulation. This file contains not only the information provided by the 
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designer in the xs file but also any default and “filler” information needed to run the 
simulation. The scenario generator uses the default values of all commands and data 
strings to create the needed values. The file name is lsnnnn.dat, where Is stands for listing 
and the nnnn represents the same four digit string used in the xs file definition. 

6.2 scenario generation procedures 

After the scenario designer has determined the parameters of the desired simulation an xs 
must be created that contains all the relevant information. A “blank” xs file, or template, is 
edited to fill in these desired parameters. 

Once completed, the xs file is then run through the scenario generator using the 
following command: 

sg xsnnnn (using the appropriate file number) 

If all information contained in the xs file has been entered in accordance with this 
guides previous sections an Is file will be generated. This Is file can then be used by the 
controller window to run the scenario. 

If any errors in the format of the xs exist the scenario generator will respond with an 
error message indicating that errors exist and in what line of the xs file they can be found. 
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#«««««««< General Items »»»»»»» 

# 

decision structure 6 

aXF GCC MEUl MEU2 CVBG ARG 
0 0 110 0 

#. - 

simulation time 2400.0 
#- 

number_of tasks 140 
#- 

simulation scale 100.0 
#.- 

numberof attributes 10 

Value Time Air Sea Ground hold Mine tank Med enemy 
#.- 

number_of resources 7 

air sea ground hold mine tank Med 

renew interval 0.5 

random seed 1 

message number 4 
#- 

comm epoch 6.0 

comm delay 5.0 

# - 

request delay 5.0 

transfer delay 10.0 

attack delay 15.0 

scramble time 0 

#- 

scramble id 0 

communication permission 
0 11111 
10 1111 
0 10 111 
0 110 11 
11110 1 
111110 

land area 0.00 40.0 30.0 100.0 
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draw line 5.0 95.0 5.0 75.0 2 
draw line 5.0 75.0 19.5 83.0 2 
draw line 19.5 83.0 26.5 83.0 2 
draw line 15.0 68.0 26.6 72.0 2 
draw line 15.0 50.0 15.0 68.0 2 
draw line 15.0 50.0 25.0 45.0 2 
#- 

draw rectangle 27.0 49.5 2.5 4.0 
draw rectangle 27.0 64.5 2.5 4.0 
draw rectangle 27.0 87.0 2.5 4.0 

penetration number 7 
#- 

penetration zone circle 0 25.00 45.00 5.00 # port area 

penetration zone circle 1 24.00 60.00 5.00 # high ground area 

penetration zone rectangle 2 26.5 70.00 4.00 6.0 # beach area one 
penetration zone rectangle 3 26.5 80.00 4.00 6.0 # beach area two 
penetration zone circle 4 5.00 95.00 5.00 # Airfield 

penetration zone circle 5 70.00 15.00 7.00 # fleet area (CVN) 

penetration zone circle 6 64.00 75.00 4.50 # fleet area (amphib) 

# 

#«««««««< Platform Class Information »»»»»»» 
platform classes 26 

# platform 0: test platform for overall coverage 
platform general 0 A GOD 0.99 1 

1 1 3000.000 3.000 20.000 
platform resource 0 50 50 50 50 50 50 50 
platform range 0 
100.00 99.00 98.00 97.00 00.00 
100.00 99.00 98.00 97.00 00.00 
100.0099.00 98.00 97.00 00.00 
platform accuracy 0 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 

# 

# platform 1: carrier based fighter aircraft 
platform general 1 A VF 0.45 1 

0 0 600.000 3.000 10.000 
platform resource 1 5200000 

platform range 1 
15.0 14.00 13.00 10.00 3.00 

15.0 14.00 13.00 10.00 3.00 

0.0 0.00 0.00 0.00 0.00 
platform accuracy 1 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

# platform 2: shore based attack fighters 
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platform general 2 A F15 0.45 1 

1 12700.00 3.00 300.00 
platform resource 2 5 1 10 0 0 0 
platform range 2 
15.00 14.00 13.00 10.00 3.00 
15.00 14.00 13.00 10.00 3.00 
0.00 0.00 0.00 0.00 0.00 
platform accuracy 2 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0 000 -1 000 

# 

# platform 3: carrier based attack aircraft 
platform general 3 A VA 0.25 1 

1 1 2700.000 3.000 10.000 
platform resource 3 0550050 
platform range 3 
15.00 14.00 13.00 5.00 3.00 
15.00 14.00 13.00 10.00 3.00 
15.00 12.00 11.00 10.00 3.00 
platform accuracy 3 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -1 000 

# 

# platform 4: carrier based MCM helicopter 
platform general 4 A MCM 0.40 1 

1 1 2700.00 3.000 10.000 
platform resource 4 0 0 0 0 2 0 0 
platform range 4 
12.00 10.00 9.00 5.00 3.00 
12.00 10.00 9.00 5.00 3.00 
12.00 10.00 9.00 5.00 3.00 
platform accuracy 4 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0 000 -1000 

# 

# platform 5: SH60 carrier/frigate helicopter 
platform general 5 A H60 0.40 1 

1 1 900.00 3.000 20.000 
platform resource 5 0 6 0 0 0 0 0 
platform range 5 
12.00 10.00 8.00 5.00 3.00 
20.00 10.00 8.00 5.00 3.00 
10.00 9.00 8.00 5.00 0.00 
platform accuracy 5 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -i.ooo 

# 
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# platform 6: amphib based attack helicopter 
platform general 6 A HCB 0.40 1 

1 1 2700.000 3.000 10.000 
platform resource 6 005 00100 
platform range 6 
12.00 11.00 10.00 5.00 3.00 
12.00 11.00 10.00 5.00 3.00 
12.00 11.00 10.00 8.00 3.00 
platform accuracy 6 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 

# 

# platform 7: amphib based troop carrier helicopter 
platform general 7 A HTP 0.45 1 

1 1 2700.000 3.000 10.000 
platform resomce 7 0055000 
platform range 7 
12.00 10.00 9.00 5.00 3.00 
12.00 10.00 9.00 5.00 3.00 
10.00 9.00 8.00 5.00 3.00 
platform accuracy 7 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

# platform 8: amphib based Medivac helicopter 
platform general 8 A HMV 0.30 1 

1 1 2700.000 3.000 15.00 
platform resource 8 0000005 
platform range 8 
12.00 10.00 8.00 5.00 3.00 

12.00 10.00 8.00 5.00 3.00 

10.00 9.00 8.00 5.00 3.00 
platform accuracy 8 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

.# 

# platform 9: amphib based engineering company helicopter 
platform general 9 A HE 0.40 1 

1 1 2700.00 3.000 20.000 
platform resource 9 0 0 0 0 5 0 0 
platform range 9 
12.00 10.00 8.00 5.00 3.00 

12.00 10.00 8.00 5.00 3.00 

10.00 9.00 8.00 5.00 0.00 
platform accuracy 9 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 
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# 


# platform 10: recon aircraft 
platform general 10 A SR7 0.50 1 

1 1 1200.000 3.000 30.000 
platform resource 10 0000000 
platform range 10 
25.00 20.00 15.00 0.00 0.01 

50.00 50.00 45.00 0.00 0.01 

50.00 50.00 45.00 0.00 0.01 

platform accuracy 10 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0 000 

# 


# platform 11: Sea bom SAM 
platform general 11 A SAM 0.99 0 

0 0 60.00 3.000 10.000 
platform resource 11 5100000 

platform range 11 
40.0 0.00 0.00 40.00 0.00 
0.00 0.00 0.00 0.00 0.00 

0.00 0.00 0.00 0.00 0.00 

platform accuracy 11 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -1 000 

# 


# platform 12: ship based NGFS support roimds 
platform general 12 A 51 0.00 0 

0 0 60.00 3.000 10.000 
platform resource 12 1 1 5 0 0 2 0 

platform range 12 
0.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 
45.00 0.00 0.00 40.00 0.00 
platform accuracy 12 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -1 000 

# 


# platform 13: stinger detachment 
platform general 13 a SD 0.4 1 

1 1 2700.000 3.000 10.00 
platform resource 13 6000000 
platform range 13 
8.00 8.00 8.00 8.00 0.00 

0.00 0.00 0.00 0.00 0.00 

0.00 0.00 0.00 0.00 0.00 

platform accuracy 13 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -LOOO 
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0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 
# 

# platform 14: Frigate 

platform general 14 S FFG 0.20 1 

1 1 2700.000 3.000 20.000 
platform resource 14 1 5 0 0 1 0 0 
platform range 14 
35.0 15.00 7.00 6.00 2.00 
35.0 15.00 7.00 6.00 2.00 
0.00 0.00 0.00 0.00 0.00 
platform accuracy 14 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

# platform 15: aircraft carrier 
platform general 15 S CVN 0.0 0 

1 1 2700.000 3.000 20.000 
platform resource 15 1100100 

platform range 15 
100.0 20.00 20.00 2.00 3.00 
100.0 20.00 20.00 2.00 3.00 
0.00 0.00 0.00 0.00 0.00 
platform accuracy 15 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

# platform 16: Cruiser 
platform general 16 S CG 0.2 1 

1 1 2700.000 3.000 20.000 
platform resource 16 110 0 10 0 

platform range 16 
40.0 20.00 20.00 00.00 3.00 
15.00 14.00 12.00 00.00 3.00 
0.00 0.00 0.00 0.00 0.00 
platform accuracy 16 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

# platform 17: Destroyer one 
platform general 17 S DDl 0.0 0 

1 1 2700.000 3.000 20.000 
platform resource 17 110 0 10 0 

platform range 17 
40.0 20.00 20.00 00.00 3.00 
15.00 14.00 12.00 00.00 3.00 
0.00 0.00 0.00 0.00 0.00 
platform accuracy 17 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 
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0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -1 000 

# 

# platform 18: Destroyer two 
platform general 18 S DD2 0.0 0 

1 1 2700.000 3.000 20.000 
platform resource 18 110 0 10 0 
platform range 18 
40.0 20.00 20.00 00.00 3.00 
15.00 14.00 12.00 00.00 3.00 
0.00 0.00 0.00 0.00 0.00 
platform accuracy 18 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -1 000 

# 

# platform 19: Amphibious assault ship (MEU 1 embarked) 
platform general 19 S LA 0.00 0 

1 1 2700.000 3.000 20.000 
platform resource 19 110 0 10 0 
platform range 19 
20.00 20.00 20.00 00.00 3.00 
15.00 14.00 12.00 00.00 3.00 
0.00 0.00 0.00 00.00 0.00 
platform accuracy 19 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0 000 -1 000 

# 

# platform 20: Amphibious assault ship (MEU 2 embarked) 
platform general 20 S LP 0.00 0 

1 1 2700.000 3.000 20.000 
platform resource 20 1 1 0 0 1 0 0 
platform range 20 
20.00 20.00 20.00 00.00 3.00 
15.00 14.00 12.00 00.00 3.00 
0.00 0.00 0.00 00.00 0.00 
platform accuracy 20 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0 000 -1000 

# 

# platform 21: Amphibious assault ship (CJTF assets embarked) 
platform general 21 S LH 0.00 0 

1 1 2700.000 3.000 20.000 
platform resource 21 1 10 0 10 0 

platform range 21 
20.00 20.00 20.00 00.00 3.00 

15.00 14.00 12.00 00.00 3.00 

0.00 0.00 0.00 00.00 0.00 
platform accuracy 21 
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0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

# platform 22: LCAC 

platform general 22 S LCl 0.25 0 

1 1 2700.000 3.000 10.000 
platform resource 22 0 0 0 0 0 0 0 
platform range 22 
0.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 
50.00 0.00 10.00 0.00 3.00 
platform accuracy 22 

0.000 0,000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

# platform 23; LCAC 

platform general 23 S LC2 0.25 0 

1 1 2700.000 3.000 10.000 
platform resource 23 0 0 0 0 0 0 0 
platform range 23 
0.00 0.00 0.0 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 
50.00 0.00 10.00 0.00 3.00 
platform accuracy 23 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

# platform 24: ground bom tracked infantry company 
platform general 24 G TG 0.09 1 

1 1 2700.000 3.000 10.00 
platform resource 24 0055010 
platform range 24 
0.00 0.00 0.00 0.00 0.00 
0.00 0.00 0.00 0.00 0.00 
50.00 30.00 10.00 5.00 3.00 
platform accuracy 24 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

# 

# platform 25: sigonella 
platform general 25 S BAS 0.00 0 
1 1 2700.00 3.000 10.000 
platform resource 25 0000000 
platform range 25 
0.00 0.00 0.00 0.00 0.0 

0.00 0.00 0.00 0.00 0.0 

0.00 0.00 0.00 0.00 0.0 



platform accuracy 25 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 - 1.000 

0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0 000 -1 000 

#- - 

# aircraft carrier carrying: fighter, CAS, anti-ship helo's 
platform subplatform 15 3 

VF VA H60 

3 2 1 

4 0 0 

# 

# cruiser carrying: SAM missiles 
platform subplatform 16 1 

SAM 

10 

-1 

# 

# Destroyer 1 (MEU 1 asset) carrying 5 Inch fire mission 
platform subplatform 17 1 

51 

10 

2 

# 

# Destroyer 2 (MEU 2 asset) carrying 5 Inch fire mission 
platform subplatform 18 1 

51 

10 

3 

# 

# amphibious ship (MEUl) carrying: AAAV and attack/troop/engineer helicopter 
platform subplatform 19 3 

HCB HTP HE 
1 1 1 
2 2 2 

# 

# amphibious ship (MEU2) carrying: troop/medivac/engineer helocopter 
platform subplatform 20 3 

HTP SD HMV 
1 1 1 

3 5 3 

# 

# amphibious ship (CJTF) carrying : mine-countermeasure helicopter/troop helo 
platform subplatform 21 2 

MCM HTP 
1 1 
0 0 

# 

# LCACl carrying: ground based infantry 
platform subplatform 22 1 
TG 
1 
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2 


# 

# LCAC2 carrying: ground based infantry 
platform subplatform 23 1 

TG 

1 

3 

# 

# sigonella base providing: troop helos 
platform subplatfonn 25 2 

F15 SR7 
1 1 
0 0 
#SP TK 

#«««««««< Task Class Information »»»»»»» 
task classes 24 

# - 

# task 0: ground mission (hill) 

task general 0 G HL 0.10 0.211 9hill.icon 

task mean 0 10.0 20.0 0.00 0.00 5.00 0.00 0.00 0.00 0.00 1.0 

task view 0 2 2 2 2 2 2 

task stealth 0 0 100.0 100.0 100.0 00.0 0.0 

task stealth 0 14 100.0 100.0 100.0 00.0 0.0 

task stealth 0 15 100.0 100.0 100.0 00.0 0.0 

task stealth 0 16 100.0 100.0 100.0 00.0 0.0 

task stealth 0 17 100.0 100.0 100.0 00.0 0.0 

task stealth 0 18 100.0 100.0 100.0 00.0 0.0 

task stealth 0 19 100.0 100.0 100.0 00.0 0.0 

task stealth 0 20 100.0 100.0 100.0 00.0 0.0 

task stealth 0 21 100.0 100.0 100.0 00.0 0.0 

task stealth 0 22 100.0 100.0 100.0 00.0 0.0 

task stealth 0 23 100.0 100.0 100.0 00.0 0.0 

task attack 0 1111111 

# 

# task 1: ground mission (airport) 

task general 1 G AP 0.00 0.211 Odullas.icon 

task mean 1 30.0 10.0 0.00 0.00 10.00 10.00 0.00 0.00 0.00 1.0 

task view 12 2 2 2 2 2 

task stealth 1 0 100.0 100.0 100.0 00.0 0.0 

task stealth 1 14 100.0 100.0 100.0 00.0 0.0 

task stealth 1 15 100.0 100.0 100.0 00.0 0.0 

task stealth 1 16 100.0 100.0 100.0 00.0 0.0 

task stealth 1 17 100.0 100.0 100.0 00.0 0.0 

task stealth 1 18 100.0 100.0 100.0 00.0 0.0 

task stealth 1 19 100.0 100.0 100.0 00.0 0.0 

task stealth 1 20 100.0 100.0 100.0 00.0 0.0 

task stealth 1 21 100.0 100.0 100.0 00.0 0.0 

task stealth 1 22 100.0 100.0 100.0 00.0 0.0 

task stealth 1 23 100.0 100.0 100.0 00.0 0.0 

task attack 1 1 111111 

# 
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# task 2: ground mission (seaport) 

task general 2 G SP 0.00 0.211 9 norfolk.icon 

task mean 2 30.0 10.0 0.00 0.00 10.00 10.00 0.00 0.00 0.00 1.00 

task view 22 2 2 2 2 2 

task stealth 2 0 100.0 100.0 100.0 00.0 0.0 

task stealth 2 14 100.0 100.0 100.0 00.0 0.0 

task stealth 2 15 100.0 100.0 100.0 00.0 0.0 

task stealth 2 16 100,0 100.0 100.0 00.0 0.0 

task stealth 2 17 100.0 100.0 100.0 00.0 0.0 

task stealth 2 18 100.0 100.0 100.0 00.0 0.0 

task stealth 2 19 100.0 100.0 100.0 00.0 0.0 

task stealth 2 20 100.0 100.0 100.0 00.0 0.0 

task stealth 2 21 100.0 100.0 100.0 00.0 0.0 

task stealth 2 22 100.0 100.0 100.0 00.0 0.0 

task stealth 2 23 100.0 100.0 100.0 00.0 0.0 

task attack 2 1 111111 

# 

# task 3: ground mission (Holding/occupying) 
task general 3 G HD 0.00 0.211 9hold.icon 

task mean 3 0.0 10.0 0.00 0.00 0.00 5.00 0.00 0.00 0.001.00 

task view 3 2 2 2222 

task stealth 3 0 100.0 100.0 100.0 00.0 0.0 

task stealth 3 14 100.0 100.0 100.0 00.0 0.0 

task stealth 3 15 100.0 100.0 100.0 00.0 0.0 

task stealth 3 16 100.0 100.0 100.0 00.0 0.0 

task stealth 3 17 100.0 100.0 100.0 00.0 0.0 

task stealth 3 18 100.0 100.0 100.0 00.0 0.0 

task stealth 3 19 100.0 100.0 100.0 00.0 0.0 

task stealth 3 20 100.0 100.0 100.0 00.0 0.0 

task stealth 3 21 100.0 100.0 100.0 00.0 0.0 

task stealth 3 22 100.0 100.0 100.0 00.0 0.0 

task stealth 3 23 100.0 100.0 100.0 00.0 0.0 

task attack 3 1 11110 0 

# 

# task 4: ground mission (Taking) 

task general 4 G TK .00 0.211 9take.icon 

task mean 4 10.0 10.0 0.00 0.00 5.00 0.00 0.00 0.00 0.00 1.00 

task view 4 2 2 2222 

task attack 4 1 11110 0 

# 

# task 5: ground contact (artillery) 

task general 5 G AT .99 0.211 2 artillery.icon 

task mean 5 2.0 10.0 0.00 0.00 0.00 0.00 0.00 2.00 0.00 1.00 

task view 5 2 2 2 2 2 2 

task stealth 5 0 100.0 100.0 100.0 100.0 00.0 

task stealth 5 1 00.0 00.0 00.0 5.0 00.0 

task stealth 5 2 00.0 00.0 00.0 5.0 00.0 

task stealth 5 3 00.0 00.0 00.0 8.0 00.0 

task stealth 5 4 00.0 00.0 00.0 00.000.0 

task stealth 5 5 00.0 00.0 00.0 00.0 00.0 

task stealth 5 6 00.0 00.0 00.0 6.0 00.0 
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task stealth 5 7 00.0 00.0 00.0 5.0 00.0 

task stealth 5 8 00.0 00.0 00.0 00.0 00.0 

task stealth 5 9 00.0 00.0 00.0 00.0 00.0 

task stealth 5 10 100.0 50.0 50.0 00.0 00.0 

task stealth 5 11 00.0 00.0 00.0 00.0 00.0 

task stealth 5 12 50.0 50.0 50.0 50.0 00.0 

task stealth 5 13 00.0 00.0 00.0 00.0 00.0 

task stealth 5 14 00.0 00.0 00.0 00.0 00.0 

task stealth 5 15 00.0 00.0 00.0 00.0 00.0 

task stealth 5 16 00.0 00.0 00.0 00.0 00.0 

task stealth 5 17 00.0 00.0 00.0 00.0 00.0 

task stealth 5 18 00.0 00.0 00.0 00.0 00.0 

task stealth 5 19 00.0 00.0 00.0 00.0 00.0 

task stealth 5 20 00.0 00.0 00.0 00.0 00.0 

task stealth 5 21 00.0 00.0 00.0 00.0 00.0 

task stealth 5 22 00.0 00.0 00.0 00.0 00.0 

task stealth 5 23 00.0 00.0 00.0 00.0 00.0 

task stealth 5 24 50.0 50.0 50.0 5.0 00.0 
task attack 5 1 111111 
# 

# task 6: ground contact (Frog launchers) 
task general 6 G FG .99 0.211 2frog.icon 

task mean 6 10.0 20.0 0.00 0.00 0.00 0.00 0.00 5.00 0.00 1.00 

task view 6 2 2 2 2 2 2 

task stealth 6 0 100.0 100.0 100.0 100.0 00.0 

task stealth 6 1 00.0 00.0 00.0 5.0 00.0 

task stealth 6 2 00.0 00.0 00.0 5.0 00.0 

task stealth 6 3 00.0 00.0 00.0 8.0 00.0 

task stealth 6 4 00.0 00.0 00.0 00.0 00.0 

task stealth 6 5 00.0 00.0 00.0 00.0 00.0 

task stealth 6 6 00.0 00.0 00.0 6.0 00.0 

task stealth 6 7 00.0 00.0 00.0 5.0 00.0 

task stealth 6 8 00.0 00.0 00.0 00.0 00.0 

task stealth 6 9 00.0 00.0 00.0 00.0 00.0 

task stealth 6 10 100.0 00.0 00.0 00.0 00.0 

task stealth 6 11 00.0 00.0 00.0 00.0 00.0 

task stealth 6 12 00.0 00.0 00.0 50.0 00.0 

task stealth 6 13 00.0 00.0 00.0 00.0 00.0 

task stealth 6 14 00.0 00.0 00.0 00.0 00.0 

task stealth 6 15 00.0 00:0 00.0 00.0 00.0 

task stealth 6 16 00.0 00.0 00.0 00.0 00.0 

task stealth 617 00.0 00.0 00.0 00.0 00.0 

task stealth 618 00.0 00.0 00.0 00.0 00.0 

task stealth 6 19 00.0 00.0 00.0 00.0 00.0 

task stealth 6 20 00.0 00.0 00.0 00.0 00.0 

task stealth 6 21 00.0 00.0 00.0 00.0 00.0 

task stealth 6 22 00.0 00.0 00.0 00.0 00.0 

task stealth 6 23 00.0 00.0 00.0 00.0 00.0 

task stealth 6 24 50.0 50.0 50.0 00.0 00.0 

task attack 6 1 111111 

# 
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# task 7: ground contact (silkworm anti-ship missile battery) 
task general 7 G SWG 0.99 0.211 1 silkworm.icon 

task mean 7 15.0 20.0 0.00 0.00 0.00 0.00 0.00 5.00 0.00 1.00 

task view 72 22 22 2 

task stealth 7 0 100.0 100.0 100.0 0.0 0.0 

task stealth 7 1 0.0 0.0 0.0 5.0 0.0 

task stealth 7 2 0.0 0.0 0.0 5.0 0.0 

task stealth 7 3 0.0 0.0 0.0 8.0 0.0 

task stealth 7 4 0.0 0.0 0.0 0.0 0.0 

task stealth 7 5 0.0 0.0 0.0 0.0 0.0 

task stealth 7 6 0.0 0.0 0.0 6.0 0.0 

task stealth 7 7 0.0 0.0 0.0 5.0 0.0 

task stealth 7 8 0.0 0.0 0.0 0.0 0.0 

task stealth 7 9 0.0 0.0 0.0 0.0 0.0 

task stealth 7 10 50.0 50.0 50.0 00.0 0.0 

task stealth 7 11 0.0 0.0 0.0 0.0 0.0 

task stealth 7 12 0.0 0.0 0.0 0.0 0.0 

task stealth 7 13 0.0 0.0 0.0 0.0 0.0 

task stealth 7 14 100.0 0.0 0.0 0.0 0.0 

task stealth 7 15 100.0 0.0 0.0 0.0 0.0 

task stealth 7 16 100.0 0.0 0.0 0.0 0.0 

task stealth 7 17 100.0 0.0 0.0 0.0 0.0 

task stealth 7 18 100.0 0.0 0.0 0.0 0.0 

task stealth 7 19 100.0 0.0 0.0 0.0 0.0 

task stealth 7 20 100.0 0.0 0.0 0.0 0.0 

task stealth 7 21 100.0 0.0 0.0 0.0 0.0 

task stealth 7 22 100.0 0.0 0.0 0.0 0.0 

task stealth 7 23 100.0 0.0 0.0 0.0 0.0 

task stealth 7 24 100.0 0.0 0.0 0.0 0.0 

task stealth 7 25 100.0 0.0 0.0 0.0 0.0 

task attack 7 1111111 

# 

# task 8: ground contact (mines) 

task general 8 GMN 0.01 0.211 2mines.icon 

task mean 8 5.0 10.0 0.00 0.00 0.00 0.00 2.00 0.00 0.00 1.00 

task view 82 2 2 2 2 2 

task stealth 8 0 100.0 100.0 100.0 100.0 02.5 

task stealth 8 1 0.0 0.0 0.0 0.0 0.0 

task stealth 8 2 0.0 0.0 0.0 0.0 0.0 

task stealth 8 3 0.0 0.0 0.0 0.0 0.0 

task stealth 8 4 0.0 0.0 0.0 0.0 0.0 

task stealth 8 5 0.0 0.0 0.0 0.0 0.0 

task stealth 8 6 0.0 0.0 0.0 0.0 0.0 

task stealth 8 7 0.0 0.0 0.0 0.0 0.0 

task stealth 8 8 0.0 0.0 0.0 0.0 0.0 

task stealth 8 9 00.0 00.0 00.0 8.0 02.0 

task stealth 8 10 0.0 0.0 0.0 0.0 0.0 

task stealth 8 11 0.0 0.0 0.0 0.0 0.0 

task stealth 8 12 0.0 0.0 0.0 0.0 0.0 

task stealth 8 13 0.0 0.0 0.0 0.0 0.0 

task stealth 8 14„ 0.0 0.0 0.0 0.0 0.0 
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task stealth 8 15 0.0 0.0 0.0 0.0 0.0 

task stealth 8 16 0.0 0.0 0.0 0.0 0.0 

task stealth 8 17 0.0 0.0 0.0 0.0 0.0 

task stealth 8 18 0.0 0.0 0.0 0.0 0.0 

task stealth 8 19 0.0 0.0 0.0 0.0 0.0 

task stealth 8 20 0.0 0.0 0.0 0.0 0.0 

task stealth 8 21 0.0 0.0 0.0 0.0 0.0 

task stealth 8 22 0.0 0.0 0.0 0.0 0.0 

task stealth 8 23 0.0 0.0 0.0 0.0 0.0 

task stealth 8 24 4.0 4.0 4.0 0.0 01.0 

task attack 8 1 111111 
# 

# task 9: sea contact (mines) 

task general 9 SMS 0.01 0.211 2mines.icon 

task mean 9 5.0 10.0 0.00 0.00 0.00 0.00 2.00 0.00 0.00 1.00 

task view 9 2 2 2 2 2 2 

task stealth 9 0 100.0 100.0 100.0 100.0 02.5 

task stealth 9 4 6.0 5.0 3.0 10.0 00.0 

task stealth 9 14 6.0 5.0 3.0 00.0 2.0 

task stealth 9 15 6.0 5.0 3.0 00.0 2.0 

task stealth 9 16 6.0 5.0 3.0 00.0 2.0 

task stealth 9 17 6.0 5.0 3.0 00.0 2.0 

task stealth 9 18 6.0 5.0 3.0 00.0 2.0 

task stealth 9 19 6.0 5.0 3.0 00.0 2.0 

task stealth 9 20 6.0 5.0 3.0 00.0 2.0 

task stealth 9 21 6.0 5.0 3.0 00.0 2.0 

task stealth 9 22 6.0 5.0 3.0 00.0 2.0 

task stealth 9 23 6.0 5.0 3.0 00.0 2.0 

task attack 9 0 111111 

# 

# task 10: air contacts (sea attackers) 

task general 10 A AS 0.4 0.211 1 air.icon 

task mean 10 15.0 20.0 5.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 

task view 10 2 2 2 2 2 2 

task attack 10 0 100011 

# 

#task 11: air contacts (ground attackers) 

task general 11 A AG 0.2 0.127 1 air.icon 

task mean 11 4.0 20.0 5.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 

task view 11 111111 

taskattackll 1111111 • 

# 

# task 12: air contacts (enemy helo) 

task general 12 A HH.18 0.211 1 helo.icon 

task mean 12 15.0 10.0 6.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 

task view 12 2 2 2222 

task attack 12 0 111111 

# 

# task 13: air contacts (neutrals) 

task general 13 A NU 0.3 0.211 0 air.icon 

task mean 13 10.0 10.0 2.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
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task view 13 22 2222 
task attack 13 0 1 1 1 1 1 1 
# 

# task 14: ground contacts (enemy tanks, vehicles) 

task general 14 G TN 0.02 0.211 2 tank.icon 

task mean 14 5.0 10.0 0.00 0.00 0.00 0.00 0.00 10.00 0.00 1.00 

task view 142 2 2 2 2 2 

task stealth 14 0 100.0 100.0 100.0 100.0 02.5 

task stealth 14 1 0.0 0.0 0.0 0.0 00.0 

task stealth 14 2 0.0 0.0 0.0 0.0 00.0 

task stealth 14 3 10.0 10.0 10.0 8.000.0 

task stealth 14 4 0.0 0.0 0.0 0.0 00.0 

task stealth 14 5 0.0 0.0 0.0 0.0 00.0 

task stealth 14 6 10.0 10.0 10.0 6.0 00.0 

task stealth 14 7 0.0 0.0 0.0 0.0 00.0 

task stealth 14 8 0.0 0.0 0.0 0.0 00.0 

task stealth 14 9 0.0 0.0 0.0 0.0 00.0 

task stealth 14 10 5.0 5.0 5.0 0.0 02.5 

task stealth 1411 0.0 0.0 0.0 0.0 00.0 

task stealth 14 12 0.0 0.0 0.0 50.0 02.5 

task stealth 14 13 0.0 0.0 0.0 0.0 00.0 

task stealth 14 14 0.0 0.0 0.0 0.0 00.0 

task stealth 14 15 0.0 0.0 0.0 0.0 00.0 

task stealth 14 16 0.0 0.0 0.0 0.0 00.0 

task stealth 14 17 0.0 0.0 0.0 0.0 00.0 

task stealth 14 18 0.0 0.0 0.0 0.0 00.0 

task stealth 14 19 0.0 0.0 0.0 0.0 00.0 

task stealth 14 20 0.0 0.0 0.0 0.0 00.0 

task stealth 1421 0.0 0.0 0.0 0.0 00.0 

task stealth 14 22 0.0 0.0 0.0 0.0 00.0 

task stealth 14 23 0.0 0.0 0.0 0.0 00.0 

task stealth 1424 8.0 6.0 6.0 3.0 02.5 

task attack 14 1 0 11111 

# 

# task 15: ground contacts (neutrals) 
task general 15 G NU 0.05 0.211 0 

task mean 15 10.0 10.0 0.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 
task view 15 222 222 
task attack 15 0 000000 

# 

# task 16: sea contact (Patrol boats) 

task general 16 S PB .05 0.211 1 ship.icon 

task mean 16 15.0 10.0 0.00 6.00 0.00 0.00 0.00 0.00 0.00 1.00 

task view 16 2 2 22 2 2 

task attack 16 0 1 0 0 0 1 1 

# 

# task 17: sea contacts (enemy submarines) 

task general 17 S SS 0.05 0.211 1 sub.icon 

task mean 17 15.0 10.0 0.00 5.00 0.00 0.00 0.00 0.00 0.00 1.00 

task view 172 2 2 2 2 2 

task stealth 17 0 100.0 100.0 100.0 100.0 02.5 
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task stealth 

17 1 

10.0 

10.0 

10.0 

0.0 00.0 

task stealth 

17 2 

10.0 

10.0 

10.0 

0.0 00.0 

task stealth 

17 3 

10.0 

10.0 

10.0 

0.0 00.0 

task stealth 

17 4 

10.0 

10.0 

10.0 

0.0 00.0 

task stealth 

17 5 

20.0 20.0 

20.0 

10.0 00.0 

task stealth 

17 6 

10.0 

10.0 

10.0 

0.0 00.0 

task stealth 

17 7 

10.0 

10.0 

10.0 

0.0 00.0 

task stealth 

17 8 

10.0 

10.0 

10.0 

0.0 00.0 

task stealth 

17 9 

10.0 

10.0 

10.0 

0.0 00.0 

task stealth 

17 10 30.0 

10.0 

10.0 

0.0 00.0 

task stealth 

17 11 

00.0 

00.0 00.0 

0.0 00.0 

task stealth 

17 12 00.0 00.0 00.0 

0.0 00.0 

task stealth 

17 13 00.0 00.0 00.0 

0.0 00.0 

task stealth 

17 14 35.0 

15.0 

7.0 

6.0 2.0 

task stealth 

17 15 

8.0 

8.0 

7.0 00.0 2.0 

task stealth 

17 16 

10.0 

9.0 

7.0 00.0 2.0 

task stealth 

17 17 

8.0 

8.0 

7.0 00.0 2.0 

task stealth 

17 18 

8.0 

8.0 

7.0 00.0 2.0 

task stealth 

17 19 

8.0 

8.0 

7.0 00.0 2.0 

teisk stealth 

17 20 

8.0 

8.0 

7.0 00.0 2.0 

task stealth 

17 21 

8.0 

8.0 

7.0 00.0 2.0 


task attack 17 0 100011 
# 

# task 18: sea contact (Sea-bom Anti-ship cmise missiles) 
task general 18 S ML 0.99 0.211 1 

task mean 18 15.0 10.0 0.00 5.00 0.00 0.00 0.00 0.00 0.00 1.00 
task view 18 2 2 2222 
task attack 18 0 100011 

# 

# task 19: sea contacts (neutrals) 

task general 19 S NU 0.05 0.211 0 ship.icon 

task mean 19 10.0 10.0 0.00 2.00 0.00 0.00 0.00 0.00 0.00 0.00 

task view 192 2 2 222 

task attack 19 0 000011 

# 

# task 20: Medivac mission 

task general 20 G MV 0.00 0.211 9 cross.icon 

task mean 20 5.0 10.0 0.00 0.00 0.00 0.00 0.00 0.00 5.00 0.00 

task view 20 2 2 2222 

task stealth 20 20 100.0 100.0 100.0 100.0 0.0 

task stealth 20 24 100.0 100.0 100.0 100.0 0.0 

task attack 20 0 1 1 1 1 1 1 

# 

# task 21: Swamp 

task general 21 G SM .00 0.211 2 swamp.icon.no_label 

task mean 21 2.0 10.0 0.00 0.00 20.00 0.00 0.00 0.00 0.00 0.00 

task view 21 2 2 2 2 2 2 

task stealth 21 0 100.0 100.0 100.0 00.0 0.0 

task stealth 21 10 100.0 100.0 100.0 00.0 0.0 

task stealth 21 14 100.0 100.0 100.0 00.0 0.0 

task stealth 21 15 100.0 100.0 100.0 00.0 0.0 
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task stealth 21 16 100.0 100.0 100.0 00.0 0.0 
task stealth 21 17 100.0 100.0 100.0 00.0 0.0 
task stealth 21 18 100.0 100.0 100.0 00.0 0.0 
task stealth 21 19 100.0 100.0 100.0 00.0 0.0 
task stealth 21 20 100.0 100.0 100.0 00.0 0.0 
task stealth 21 21 100.0 100.0 100.0 00.0 0.0 
task stealth 21 24 100.0 100.0 100.0 00.0 2.0 
task stealth 21 25 100.0 100.0 100.0 00.0 0.0 
task attack 21 1 111111 
# 

# task 22: Air contact (silkworm anti-ship missile battery) 
task general 22 A SWA 0.99 0.211 2 silkworm.icon 

task mean 22 15.0 20.0 0.00 0.00 0.00 0.00 0.00 5.00 0.00 1.00 

task view 22 2 2 2 2 2 2 

task stealth 22 0 100.0 100.0 100.0 100.0 0.0 

task stealth 22 1 0.0 0.0 0.0 0.0 0.0 

task stealth 22 2 0.0 0.0 0.0 0.0 0.0 

task stealth 22 3 0.0 0.0 0.0 0.0 0.0 

task stealth 22 4 0.0 0.0 0.0 0.0 0.0 

task stealth 22 5 0.0 0.0 0.0 0.0 0.0 

task stealth 22 6 0.0 0.0 0.0 0.0 0.0 

task stealth 22 7 0.0 0.0 0.0 0.0 0.0 

task stealth 22 8 0.0 0.0 0.0 0.0 0.0 

task stealth 22 9 0.0 0.0 0.0 0.0 0.0 

task stealth 22 10 50.0 50.0 50.0 0.0 0.0 

task stealth 22 11 0.0 0.0 0.0 0.0 0.0 

task stealth 22 12 0.0 0.0 0.0 0.0 0.0 

task stealth 22 13 0.0 0.0 0.0 0.0 0.0 

task stealth 22 14 100.0 50.0 50.0 0.0 0.0 

task stealth 22 15 100.0 50.0 50.0 0.0 0.0 

task stealth 22 16 100.0 50.0 50.0 0.0 0.0 

task stealth 22 17 100.0 50.0 50.0 0.0 0.0 

task stealth 22 18 100.0 50.0 50.0 0.0 0.0 

task stealth 22 19 100.0 50.0 50.0 0.0 0.0 

task stealth 22 20 100.0 50.0 50.0 0.0 0.0 

task stealth 22 21 100.0 50.0 50.0 0.0 0.0 

task stealth 22 22 100.0 50.0 50.0 0.0 0.0 

task stealth 22 23 100.0 50.0 50.0 0.0 0.0 

task stealth 22 24 100.0 50.0 50.0 0.0 0.0 

task stealth 22 25 100.0 50.0 50.0 0.0 0.0 

task attack 22 1 111111 

# 

# task 23: Dummy task with no value 

task general 23 A DUM 0.99 0.211 2 

task mean 23 0.0 0.0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 

task view 23 2 2 2 2 2 2 

task attack 23 0 0 0 0 0 0 0 

task penetration 0 000 00 00 
task penetration 1 0000000 
task penetration 2 0000000 
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task penetration 3 0000000 
task penetration 4 0000000 
task penetration 5 0011000 
task penetration 60011000 
task penetration 7 000001 1 
task penetration 8 0000000 
task penetration 9 0000000 
task penetration 10 000001 1 
task penetration 11 0 0 1 1 0 0 0 
task penetration 12 000001 1 
task penetration 13 0000000 
task penetration 14 0000000 
task penetration 15 0000000 
task penetration 16 000001 1 
task penetration 17 0000011 
task penetration 18 0 0 0 0 0 1 1 
task penetration 19 0000000 
task penetration 20 0000000 
task penetration 210000000 
task penetration 22 0 0 0 0 0 1 1 
# 

end__of_class_info 

# 

#«««««««< State Information »»»»»»» 
# 

platform number 11 
#- 

platform definition 0 CVN 4 70.0015.00 
platform definition 1 CG 4 88.00 54.00 
platform definition 2 FFG 4 90.00 50.00 
platform definition 3 DDl 5 40.00 73.00 
platform definition 4 DD2 5 40.00 78.00 
platform definition 5 LA 5 64.00 73.00 
platform definition 6 LP 5 64.00 77.00 
platform definition 7 LH 5 64.00 75.00 
platform definition 8 LCl 2 60.00 73.00 
platform definition 9 LC2 3 60.00 75.00 
platform definition 10 BAS 0 96.00 04.00 
#platform definition 11 GOD 0 50.00 50.00 
# 

# - 

#TASK DEFINITIONS 
# 

# Tasks 200-225 (swamp areas) 

# 

task definition 200 21 1 0 
# 

task definition 201 21 10 
# 

task definition 202 21 1 0 








# 

task definition 203 21 1 0 
# 

task definition 204 21 1 0 
# 

task definition 205 21 1 0 
# 

task definition 206 21 1 0 
# 

task definition 207 21 1 0 
# 

task definition 208 21 1 0 
# 

task definition 209 21 1 0 
# 

task definition 210 21 1 0 
# 

task definition 211 21 10 
# 

task definition 212 2110 

# 

task definition 213 21 1 0 
# 

task definition 214 21 1 0 
# 

task definition 215 21 1 0 

# 

task definition 216 21 1 0 

# 

task definition 217 21 1 0 
# 

task definition 218 21 10 
# 

task definition 219 21 1 0 

# 

task definition 220 21 1 0 
# 

task definition 221 21 10 
# 

task definition 222 21 1 0 

# 

task definition 223 21 1 0 
# 

task definition 224 21 1 0 
# 

task definition 225 21 1 0 


Tasks 226-230 (ground mines) 
task definition 226 23 1 0 



# 

task definition 111 23 1 0 
# 

task definition 228 23 1 0 

# 

task definition 229 23 1 0 
# 

task definition 230 23 1 0 
# 

# - 


# Tasks 231-235 (ground contacts - enemy) 
task definition 231 23 1 0 

# 

task definition 232 23 1 0 
# 

task definition 233 23 1 0 
# 

task definition 234 23 1 0 
# 

task definition 235 23 1 0 
# 

# --- 

# Tasks 236-240 (sea mines) 


# 

task definition 236 9 00 
# 

task definition 237 9 0 0 
# 

task definition 238 9 0 0 
# 

task definition 239 23 0 0 
# 

task definition 240 23 0 0 
# 

# Tasks 241-250 (artillery) 

# 

task definition 241 5 10 
# 

task definition 242 5 10 
# 

task definition 243 5 1 0 
# 

task definition 244 5 1 0 
# 

task definition 245 5 1 0 
# 

task definition 246 5 10 
# 

task definition 247 5 1 0 
# 






task definition 248 5 10 
# 

task definition 249 5 10 
# 

task definition 250 5 1 0 
# 

# - 

# Tasks 251-255 (ground contacts - enemy) 

# 

task definition 251 23 1 0 
# 

task definition 252 23 1 0 
# 

task definition 253 23 1 0 
# 

task definition 254 23 1 0 
# 

task definition 255 23 1 0 
# 

# - 

# Tasks 256 - 260 (ground mines) 

# 

task definition 256 8 1 0 

# 

task definition 257 8 1 0 

# 

task definition 258 23 1 0 
# 

task definition 259 23 1 0 

# 

task definition 260 23 1 0 

# 

# - 

# Tasks 261-265 (aircontacts, anti-shipping) 

# 

task definition 261 10 0 1 
# 

task definition 262 10 0 1 
# 

task definition 263 23 0 1 
# 

task definition 264 23 0 1 
# 

task definition 265 23 0 1 
# 

# - 

# Tasks 266-270 (aircontacts, anti-ground) 

# 

task definition 266 23 1 1 
# 

task definition 267 23 1 1 
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# 

task definition 26S 23 1 1 

# 

task definition 269 23 1 1 
# 

task definition 270 23 1 1 
# 

# - 

# Task 271-275 (air contacts - helicopter) 

# 

task definition 271 12 0 3 
# 

task definition 272 12 0 3 
# 

task definition 273 23 0 3 
# 

task definition 274 23 0 3 
# 

task definition 275 23 0 3 
# 

# Task 276-280 (air contacts - neutral) 

# 

task definition 276 13 0 3 
# 

task definition 277 23 0 3 
# 

task definition 278 23 0 3 
# 

task definition 279 23 0 3 
# 

task definition 280 23 0 3 
# 

# Task 281-285 (ground contacts - frog launchers) 

# 

task definition 281 6 13 

# 

task definition 282 23 1 3 

# 

task definition 283 23 1 3 
# 

task definition 284 23 1 3 
# 

task definition 285 23 1 3 
# 

#. - 

# Task 286-290 (ground contacts - silkworm launchers) 

# 

task definition 286 7 1 3 #(ground) 

# 
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task definition 287 23 1 3 
# 

task definition 288 23 1 3 
# 

task definition 289 22 1 3 #(air) 

# 

task definition 290 23 1 3 
# 

# - 

# Task 291-295 (medivac mission) 

# 

task definition 291 23 0 3 
# 

task definition 292 23 0 3 
# 

task definition 293 23 0 3 
# 

task definition 294 23 0 3 
# 

task definition 295 23 0 3 
# 

# - 

# Task 296-300 (sea contacts - submarine) 

# 

task definition 296 17 0 3 

# 

task definition 297 17 0 3 

# 

task definition 298 23 0 3 

# 

task definition 299 23 0 3 

# 

task definition 300 23 0 3 

# 

#- 

# Task 301-305 (sea contacts - patrol boats) 

# 

task definition 301 16 0 3 
# 

task definition 302 16 0 3 
# 

task definition 303 23 0 3 
# 

task definition 304 23 0 3 
# 

task definition 305 23 0 3 
# 

# - 

# Tasks 306-314 (ground missions) 

# 

task definition 306 0 1 0 #(hill) 







# 

task definition 307 2 1 0 #(port) 

# 

task definition 308 1 1 0 #(airport) 

# 

task definition 309 4 1 0 #(taking beach one) 
# 

task definition 310 4 10 #(taking beach two) 
# 

task definition 311 3 10 
# 

task definition 312 23 1 0 

# 

task definition 313 23 1 0 
# 

task definition 314 23 1 0 
# 

# --- 

# Tasks 315-319 (ground mines) 

# 

task definition 315 23 1 0 

# 

task definition 316 23 1 0 
# 

task definition 317 23 1 0 
# 

task definition 318 23 1 0 
# 

task definition 319 23 1 0 

# 

# - 

# Tasks 320- 324 (ground contacts - enemy) 
task definition 320 14 1 0 

# 

task definition 321 14 1 0 

# 

task definition 322 23 1 0 

# 

task definition 323 23 1 0 
# 

task definition 324 23 1 0 
# 

# Task 325-329 (sea contacts - neutrals) 

# 

task definition 325 19 0 3 

# 

task definition 326 23 0 3 
# 

task definition 327 23 0 3 
# 







task definition 328 23 0 3 
# 

task definition 329 23 0 3 
# 

# - 

# Task 330-334 (ground contacts - silkworm launchers) 

# 

task definition 330 23 1 3 
# 

task definition 331 23 1 3 
# 

task definition 332 23 1 3 
# 

task definition 333 23 1 3 
# 

task definition 334 23 1 3 
# 

#- -- 

# Task 335-339 (medivac mission) 

# 

task definition 335 20 0 3 
task attribute 335 

10.0 20.0 0.00 0.00 0.00 0.00 0.00 0.00 5.00 0.00 

# 

task definition 336 20 0 3 
# 

task definition 337 23 0 3 
# 

task definition 338 23 0 3 

# 

task definition 339 23 0 3 

# 

# 

task prerequisites 310 3 236 237 238 
# 

# - 

# 

task spawn 306 1 A 311 

task spawn 310 4 A 320 321 335 336 

task spawn 286 1 D 289 

# 

#«««««««< Maneuver Information »»»»»»» 

NOTE - SPECIFIC EXAMPLES ONLY OF MANEUVERS PROVIDED 

# Tasks 200-220 (swamp areas) 

# 

maneuver definition 200 1.000 
s 18.0 89.0 3600.0 
e 18.0 89.0 0.0 
# 

# - 
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# Tasks 226-230 (ground mines) 

# 

maneuver defmition 226 6000.000 
s 15.0 60.0 3600.0 
e 15.0 60.0 0.0 
# 

# - 

# Tasks 236-240 (sea mines) 

# 

maneuver definition 236 10.00 
s 33.0 80.5 3600.0 
e 33.0 80.5 0.0 
# 

# - 

# Tasks 241-250 (artilery) 

# Artillery positions: site one: (12.0 67.0 - north) 

# site two: (15.0 88.0 - south) 

# 

maneuver definition 241 500.0 
s 12.0 67.0 300.0 
m 12.0 67.0 0.99 
e 27.5 72.5 0.0 
# 

# - 

# Tasks 251-255 (ground contacts - enemy) 

# 

maneuver definition 251 6000.00 
s 22.0 70.0 3600.0 
e 22.0 70.0 0.0 
# 

# - 

# Tasks 261-265 (aircontacts, anti-shipping) 

# 

maneuver definition 261 900.00 
m 1.00 20.0 0.9 
e 75.0 20.0 0.0 
# 

# - 

# Tasks 266-270 (aircontacts, anti-ground) 

# 

maneuver definition 266 6000.000 
s 10.0 70.0 3600.0 
e 10.0 70.0 0.0 
# 

# - 

# Task 271-275 (air contacts - helicopter) 

# 

maneuver definition 271 600.000 
m 5.0 95.0 0.9 
e 64.0 75.0 0.0 
# 
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# Task 276-280 (air contacts - neutral) 

# 

maneuver definition 276 6.000 
m 10.0 70.0 0.50 
e 99.0 70.0 0.0 
# 

# - 

# Task 281-285 (ground contacts - frog launchers) 

# 

maneuver definition 281 720.000 
s 3.00 85.0 1200.0 
m 3.00 85.0 0.88 
e 28.0 83.0 0.00 
# 

# - 

# Task 286-290 (groimd contacts - silkworm launchers) 

# 

maneuver definition 286 1200.000 
s 28.5 51.5 720.0 
e 28.5 51.5 0.0 

# 

# - 

# Task 291-295 (medivac mission) 

# 

maneuver definition 291 6000.000 
s 28.0 73.0 3600.0 
e 28.0 73.0 0.0 

# 

# - 

# tasks 296-300 (sea contacts - submarines) 

# 

maneuver definition 296 120.000 
m 99.0 40.0 0.9 
e 75.0 20.0 0.0 
# 

# - 

# Task 301-305 (sea contacts - patrol boats) 

# 

maneuver definition 301 600.000 
m 32.0 38.0 0.99 
e 70.0 20.0 0.0 

# 

# - 

# tasks 306-314 (ground missions) 

# 

maneuver definition 306 1.000 #(hill) 
s 25.00 60.00 3600.0 
e 25.00 60.00 0.00 
# 
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APPENDIX B [ DDD Tutorial ] 


1. The DDD Graphical User interface 

The DDD graphical user interface displays a map on the left side of the screen which is 
a graphical representation of friendly and enemy objects. Within the map, land is 
represented by squares which have a brown tint, and sea by squares which are white. The 
mouse commands listed in the next section will describe how friendly objects on the map 
may be manipulated and how information on enemy objects is obtained. The right half of 
the screen contains four buttons: 

Start/Refresh: The Start button is used only at the beginning of a scenario to start all 
of the stations playing. Once the scenario has begim, the button changes to Refresh. 

Left clicking on the Refresh button redraws the map eliminating any undesired traces 
which may appear. 

Zoom In: Allows the user to zoom in for a more detailed look at a particular section of 
the map. To zoom in, left click on the “Zoom In” button. Move the cursor over to map 
and left click at a point to the left or right of where the area of interest lies. While 
continuing to hold the left mouse button depressed, drag the cursor and a box will 
begin to appear showing the area which will be zoomed in on. 

Zoom Out: Left clicking on this button returns the map to the previous map size. 

Cancel: Left Clicking on the Cancel button allows the user to suspend an operation on 
an asset such as a move or an attack prior to completing the task. 

The right half of the screen also contains a time bar. When a fnendly object (platform 
or sub-platform) is selected to perform an action (i.e. launch aircraft, attack a task), a white 
arrow will appear next to this bar showing the amount of time to complete this task. The 
object cannot perform any other action until this action is completed. In addition, above the 
time bar are several other pieces of information. The color of the stick man figure in a box 
shows the color of the objects on the map which your station controls. Next to the this box 
is the name of the station you are playing (i.e. CJTF, MEU 2, etc.) Below the box are two 
counters which display feedback on how well the entire team is doing on the scenario. The 
counter labeled mission starts at zero and increments as tasks are accomplished. The 
counter labeled strength starts at 100 and decrements as your force strength is decreased. 

The lower portion of the screen contains two window dialog boxes. Close attention 
must be given to the window on the left as this box displays messages between the various 
players which may require some action to be taken by your station. The right window can 
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best be described as a confirmation window. Summaries of messages or actions performed 
by your station will appear in this window along with some messages about the status of 
other friendly objects. Also, the very bottom of the screen below these two windows 
displays warning and error prompts. A beep will occur along with a warning or error 
message following any action performed by your station which is not allowed (i.e. 
Attempting to attack the enemy when your unit is out of range). 

2. Using the Mouse in DDD 

A standard three button mouse is used when running a scenario at each workstation. 
When clicking on an object in DDD each mouse button serves a different function 
depending on whether the object is friend or foe, and if friend whether or not the object is 
owned or not owned by you. 

Left Mouse Button: The left mouse button clicked on an object will just select it. The 
left mouse button is also used to carry out options selected from the menu presented 
when an object is right clicked on. 

Middle Mouse Button: When the middle button is clicked on an object, the window 
presented depends on whether the object is a (1) friendly platform or sub-platform or 
(2) enemy platform or task. If the object is an enemy platform or task, a window 
appears which provides known information about the attributes of the object. If a 
fiiendly object is selected, a screen appears which displays the attributes of that 
platform or sub-platform. If a platform is selected the attributes, ownership, and 
nuinber of all sub-platform located on the platform are also shown. Platforms are the 
major fiiendly objects in the scenarios. Sub-platforms are objects such as aircraft. 
Naval Surface Fire Support missions, standard missile missions, helicopters, etc. which 
are earned by a platform. The ownership of any sub-platform may or may not be the 
same as the owner of the platform it is being carried on. 

When a fiiendly platform is selected with the middle mouse button, the portion of 
the window where the sub-platforms are listed is used to launch or request launch of a 
sub-platforms depending on where the sub-platform is located. There are thr ee, possible 
situations which can occur here: 

!• S ub-platform needed to be launched i s on a platform owned hv vou : In this case 
you can launch any sub-platform on your platform whether you own it or not. This 
is done by left clicking on the right arrow key in the line for the number of sub- 
platform(s) needed and then clicking OK.. 

Sub-pl^tform needed to be laimched and which is owned bv vou is Inea^eH nn a 
platform which yQU do net qwp; In this case middle click on the platform where 
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your sub-platform is located. Left click on the arrow located in the line of the sub¬ 
platform needed imtil the desired number of sub-platforms to be launched is set, 
and then left click on OK. A message will then be sent to the owner of the platform 
where your sub-platform is located requesting that it be launched. It is the 
responsibility of the person where your sub-platform resides to laimch it. 

3. Sub-platform needed is not owned bv vou and is located on a platform not owned 
bv you: In this case middle click on the platform where the sub-platform needed 
resides. Left click on the arrow on the line containing the sub-platform desired until 
the required number is set, and then left click on OK. A message will then be 
forwarded up your chain of command which must be acted upon by your immediate 
superior to obtain this sub-platform. 

The lower portion of this screen also offers options for displaying information on range 
rings for both sensors and weapons of a friendly object against either enemy groimd, air, or 
sea assets. The sensor option will display four range rings around the object. The outermost 
black ring represents the detection range; the next inner black ring represents the range at 
which measurements on the enemy can be made; the furthest inner black ring represents 
the visual detection range; and the iimer yellow ring represents the range at which the 
object is vulnerable. The weapons option displays a single red ring arormd the object 
which shows the effective range of its weapon. To display these range rings left click on 
either sensors, weapon, or both, and then left click what type of medium to display these 
for (air, ground, or sea). To turn the range rings off, middle click on the object and left 
click on none. 

Right Mouse Button: The right mouse button will cause a menu to pop up with the menu 
options depending on ownership of the object and whether it is a fiiendly or enemy object 
or task. The following sections describe the options presented depending on the object 
selected with the right mouse button. 

1. Friendly object which vou do not own: The menu that pops up will present the 
option of requesting the asset, forcing the transfer of the asset, or information on the 
asset. Explanations of these options follow: 

Request (REQ): A menu will pop which allows selecting who the request is to, 
and the vugency of the request. All items must be selected. When the choices are 
completed, a message is sent to the person selected if they are directly in your chain 
of conunand or up your chain of conunand where your superior must take action on 
the request. 

Force Transfer (FORCE XFR); This option may only be used if the station you 
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are playing is superior to someone else in the scenario (i.e. CJTF, MCC, or GCC). 
Units may only be forcibly transferred which are under control of a person 
subordinate to you. When this option is selected, a menu will pop up which lists the 
other players in the scenario. Left click on the person the asset is desired to be 
forcibly transferred to and click OK. The object will be transferred to the person 
selected provided the object is transferable object. 

Information (INFO): Same as middle clicking on the object. 

Friendly obiect which you own: This menu will allow the choices of Move, Pursue, 
Attack, Return, Transfer, or Information. An explanation of these options follow: 


Move: Selecting move will cause a cross-hair type symbol to appear. Position thi s 
cross hair to the place the object is desired to be moved and single click with the 
left mouse button. The object will then move to this position. When it arrives there, 
it will stop until another command to move is given. 

Pursue: Selecting pursue will cause the cursor to change to a finger. Place the 
finger on the enemy object desired to be pursued, left click, and your object will 
then move to pursue it. 

Attack: Attack in DDD does not only have the connotation of physically 
performing destruction on an object, but also implies that the object selected will 
carry out a task of some sort. When this option is selected a question mark will 
appear. Place the question mark on the object or task an action is to be performed 
on. If in range to perform the this action, a menu will then appear which shows the 
attributes of the object selected to perform the task and the attributes of the object 
that the task to be performed on. The option is then given to carry out the task or to 
cancel the assignment. If the object selected to attack the enemy does not have 
enough combat power to accomplish the task, a coordinatftd attack may be 
performed. It should be noted that the folloAving explanations of how to do a 
c oordinated attack.will work only if a ll of the objects are within aftar.k rangp A 
g pprdinatgd attack using two objects is accomplished by first selecting one of the 
two objects to perform the coordinated attack with the left mouse button, and then 
right clicking on the second object performing the attack. The menu will then pop 
up and select the attack option. The cursor will then change to the question mark. 
Place it on the object which is to be attacked and left click with the mouse. To 
perform a ppordinated attack wi& three or more o bjects, left click on the first object 
performing the attack. Then, while holding the shift key down on the keyboard, left 
click on all but one of the remaining objects performing the attack. Release the 
shift key and right click on the final object. The menu will pop up and select attack. 
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The cursor will change to a question mark. Place it on the object to be attacked and 
left click. 

Return: This option may only be used for sub-platforms. Selecting this option will 
cause the sub-platform to return to the platform it originated fi'om. The sub¬ 
platform will not move towards its originating platform, but instead will change to 
a box with a “x” in it to simulate returning to its originating platform. The return 
option has been disabled on some sub-platforms in the scenario. If one of these sub¬ 
platforms is directed to return, an error message will appear. 

Transfer (XFR); Used to transfer control of an object from one person in the chain 
of command to another, and to inform another player that an object requested for 
transfer will not be transferred. When selected, a menu will pop up showing all 
members of the chain of command. Select the person to whom control is to be 
passed or to whom a request for transfer is to be denied by left clicking on that 
person. Then, to transfer control ensure the “transfer right now” button is depressed 
and click OK; or to send a message denying the request left click on “I can’t 
transfer right now” and click OK. The object will then transfer control to the person 
selected or a message will be sent informing them that the request for transfer has 
been denied. 

Information (INFO): Same as middle clicking on the object. 

Enemy Objects or Tasks: The menu presented in this instance presents the options of 

Identify, Requesting Information, Transferring Information, Coordinating Action, 

Assigning, and Information. Explanations of these options follow: 

Identify: This option is normally used to identify enemy objects or tasks for which 
the identity is unknown. This will be readily apparent in a scenario as the first letter 
shown with the icon will be followed by a question mark. The first letter designates 
which medium the unknown contact operates in. “A?” implies an unknown air 
contact; “G?” implies an unknown ground contact; “S?” implies an unknown sea 
contact. Selecting the identify option will cause a menu to pop up which shows the 
known attributes of the object or task as seen by each player in the scenario. If a 
friendly object having sensors capable of identifying the enemy object or task is 
within sensor range the object will be identified correctly. If not, the question mark 
will remain. This will be apparent by looking at the lower left hand column where 
the identity will be shaded from a list of possible identities. Click the fused button 
near the top left hand comer and then OK. The identity of the object will then 
appear correctly on the map and its icon will change to its correct identity. 
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The following tables give descriptions of the two letter symbols which will be the options 
shown when identifying an object: 


Unknown Ground 

Description 

1.1 

Unknown Air 

Description 

? 

unknown 

■ 

V 

Unknown 

Hl 

Ground mission or taking a hill 


Ab 

bnemy attack against snips 

AP 

Airport ground mission 


-AG- 

bnemy attack against ground force 

bP 

Seaport ground mission 


-RH- 

bnemy helo attack against ships 

MD 

fioiding or occupying ground 

■ 

-RD- 

Neutral 

IK 

Taking a ground mission 


SWA 

Silkwomn missile in lltgm 

AT 

bnemy artillery ““ 




l-U 

bnemy Frog launcher 

1 

Unknown sea 

uescnpiion 

SWG 

Enemy silkwomi missile launcher 

i 


Unknown 

TN 

bnemy tanks, troops, or vehicles 

■ 

MS' 

Sea mines ^ 

NU 

... tJULI ..— 

Neutral -- 

■ 

-PB- 

bnemy patrol boats 

MN 

Land Mines ~ 


G5- 

bnemy subrnannes 

-- — 



- fK - 

bnemy anti-ship cruise missiles 




- m - 

Neutral ^ 


Request Information (REQ INFO): Selecting this option will cause a menu to 
pop up which allows selecting anther player or all other players you wish 
information on the enemy object or task from . Select the person(s) and click OK. A 
message will then be sent to the person(s) notifying them that this information is 
requested. 


Transfer Information (XFR INFO): Selecting this option will cause a menu to 
pop up which allows selecting a particular individual or all other players you wish 
information on the enemy object or task to be sent to. Select the person(s) and click 
OK. A message will then be sent to the person(s) selected. 

Coordinate Action (CRD ACTION): The use of this option allows messages to 
be sent between players concerning action requests, support, or intent against an 
enemy object or task. When selected, a menu pops up displaying options for 
choosing who the message is to sent to and a list of messages which may be sent. 
The following messages may be sent: 

1.1 plan to handle. 

2.1 plan to support. 

3.1 cannot handle. 

4.1 cannot support. 

5. Can you handle ? 

6. Can you support ? 

Select the person the message is to be sent to, a message is to be sent, and click OK. 
The message will then be sent to the person selected. 
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Assign: This option may only be used if you are playing a position where you are 
superior to someone in the chain of command and may only be directed at those 
people who are subordinate to you. This option will cause a question mark to 
appear. Place it on the enemy object or task desired to be assigned and left click. A 
menu will then appear which allows selecting whom in the chain of command it is 
to be assigned to. Left click on the person desired to assign the task to and click 
OK. A message will then be sent to that person notifying them they are responsible 
for taking care of the task. 

Information (INFO): Same as middle clicking on the object. 

3.0 List of Objects in the Scenario 
Terrain and task objects 

The following shows representations of the icons which represents terrain or task 
objects in the scenarios. 




, Swamp: The swamp icon indicates areas which mechanized or infantry units should 
not traverse . Friendly units will not be destroyed by going into these areas, but total 
strength will be diminished. 


IHI Airfield: The airfield icon is used twice in the scenarios. The enemy has one 
airfield which is the objective or task to completed by MEU 2. This airfield has attributes 
associated with it which must be compared to the attacking force attributes to determine if 
the necessary force is available. The second airfield is fiiendly owned and controlled by the 
CJTF. It contains additional assets such as an SR-71 and F-15’s which are also under 
control of the CJTF. 


f:F Port: The port is the objective or task of MEU 1. It, like the airfields, also 

has attributes which must first be determined and compared to attacking forces attributes to 
determine if enough combat power can be brought to bare to achieve this objective. 




Hill: The hill is commanding terrain between the port and airfield which must be 
captured by MEU 1. It is surrounded by swamps on both sides which means the only way 
of accomplishing this task is by using heli-bome assault troops (HTP sub-platform). 


* Task: The task icon has attributes which must first he identified and then a 
determination made as to the best asset available to complete this task. Tasks are normally 
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used to represent enemy ground forces in a given location which must be eliminated. 

Medivac: The medivac icon is a task which may appear after fiiendly ground 
platforms or sub-platforms engage enemy objects or tasks. The task has attributes which 
must be determined. The task is completed by attacking it with the medivac helicopter 
(HMV sub-platform). 


The hold icon may appear after completion of a task (i.e. attacking the 
hill). If this occurs the asset used to perform the task must remain in its current position 
and may not be used to perform any other task. 


Enemy Assets 

The following section shows the icons which represent enemy forces that may or may 
not appear in a scenario. The text which follows each icon describes the enemy objects 
capabilities and the fiiendly weapon of choice to use against it. 

Artillery: Enemy artillery pieces may pop up at various times. When they appear, 
they take approximately 15 minutes to set up before they are able to fire. They pieces are 
stored in remforced concrete bunkers with the ammunition stored in deep underground 
bunkers. The only method in which enemy artillery may be suppressed is throu gh the use 
of Naval Surface Fire support (NSFS). Once the artillery pieces begin to move toward you, 
which simulates firing, you will be vmable to attack them. 


Mines: The enemy possesses the possibility of deplo)dng both land and sea based 
mines. If encountered and moved through by fiiendly forces the total eftectiveness of these 
forces will be diminished. Sea based mines may only be cleared by the use of a mino 
clearing helicopter (MCM sub-platform) located on the ARG ships. Land mines may only 
be cleared through the use of the engineering platoon owned by MEU 1 (HE sub¬ 
platform). 


Jl. Frog Missile sites: These sites are capable of launching short range missiles 
containing chemical mumtions. The laimchers take approximately 30 minutes to set up. 
Naval Siuface Fire Support is ineffective at suppressing these launchers. Suppression must 
be done through the use of Close Air Support (CAS) aircraft carrying precision guided 
munitions located on the aircraft carrier (VA sub-platform). 


^ Silkworm Missile Site: The enemy has placed silkworm missile sites in residential 
areas near the port. The appearance of a silkworm site requires visual confirmation through 
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use of the SR-71 (SR7 sub-platform) prior to attacking the site. The site may only be 
destroyed by using CAS carrying precision guided munitions (VA sub-platform). 


Submarines: The enemy submarines are Kilo class diesel boats. They can only be 
destroyed using the FFG platform. 


Ship: The only ships the enemy possesses are fast patrol boats. These can only be 
destroyed by using the SH-60 helicopters (H60 sub-platform) which carry penguin 
missiles. 


Helicopter: The enemy possesses Hind helicopters capable of carrying Exocet anti¬ 
ship missiles. These helicopters are very low flyers which precludes the use of standard 
missiles to defend against Aem. The only friendly asset capable of destroying them are the 
stinger platoon (SD sub-platform) located on one of the ARG ships. 


Aircraft: Enemy aircraft may laimch attacks against the ARG or the CVBG. 
Aircraft may be destroyed by using either standard missiles (SAM sub-platform) located 
onboard the Aegis cruiser or by using fighter aircraft (VF or FI5 sub-platforms) located on 
the carrier or at the Sigonella airbase. 


Tanks: Enemy tanks may be encountered along the road for the assaults on both the 
airfield and the port. The tanks can only be seen when within the detection range of 
friendly ground forces. If friendly forces move out of range the tank icon will disappear. 
Tanks can only be destroyed by using the Cobra helicopters (HCB sub-platform) armed 
with TOW missiles which are located on the ARG ships. 


Unknown Enemy Object: When this icon appears it must first be identified to 
determine what it is. The icon will have a letter designation followed by a “?”. “A” implies 
unknown air; “G” implies unknown ground; and “S” implies unknown sea. The object 
must be identified with a suitable friendly platform or sub-platform. Identification of 
unknown groimd objects may only be accomplished using the SR-71 (SR7 sub-platform) 
located at the Sigonella airbase. 


Friendly Assets 


□ Friendly Platform Icon: This icon is used to represent friendly platforms in a 
scenario. The middle of the box will contain a letter to show the type of medium in which 
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the platform operates. The letter “G” implies a ground asset; the letter “S’ implies a sea 
asset; and the letter “A” implies an air asset. An additional letter and number designator 
will be shown on the map above the icon for further identification (i.e. CVN-000). 
Platform icons are color coded to show ownership. 

Friendly Sub-platform Icon: When laimched from its parent platform a sub¬ 
platform will appear as circle with a letter and number combination above it for further 
identification (i.e. MCM-101). The middle of the circle will contain a letter to show the 
type of medium in which the platform operates. The letter “G” implies a ground asset; the 
letter “S implies a sea asset; and the letter “A” implies an air asset. Sub-platform icons are 
also color coded to show ownership. 


Friendly Platform/Sub-platform Busy Icon: When a platform or sub-platform is 
directed to perform some task such as attacking; transfer ownership between players; 
laimch a sub-platform; or when a sub-platform is directed to return, the icon will change to 
a box with a x in it. The platform or sub-platform cannot be directed to perform any 
other function until this task is completed. At the end of the task it will change back to its 
previous form. 

Chain of Co mma nd 

One of the following organizational structures will be used in the running of the 
scenario depending on which scenario is being run. 



Commander Joint Task Force (CJTF): Overall commander of the operation as 
delineated in the oporder. The CJTF owns the Sigonella airbase and various sub-platforms 
in the scenarios. Units controlled by the CJTF in a scenario will be black in color. 


Ground Component Commander (GCC): Reports directly to the CJTF when used in the 
chain of command. Responsible for coordination of the ground assets of MEU 1 and MEU 
2 as delineated in the oporder. Units controlled by the GCC will be green in color. 
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Maritime Component Commander (MCC): Reports directly to the CJTF when in the 
chain of command. Responsible for coordination of maritime assets of the ARG and 
CVBG as delineated in the oporder. Units controlled by the MCC will be green in color. 

Amphibious Ready Group (ARG): The ARG controls a group of three amphibious ships 
consisting of a LHA, LPD, and a LHD, and two Spruance class destroyers. Units under the 
ARG’s control are orange in color. 

Carrier Battle Group (CVBG): The CVBG controls a battlegroup consisting of a Nimitz 
class carrier, a Ticonderoga class cruiser, and an Perry class frigate. Units under the 
CVBG’s control will be red in color. 

Marine Expeditionary Unit (MEU 1 & MEU 2): The two MEU’s each own there own 
LCAC for transporting troops ashore for an amphibious assault. Each LCAC carries the 
infantry portion of the MEU moimted in AAV’s for mobility once they reach the shore. 
Each MEU also owns helicopter assets which reside on the ARG. Units imder MEU 1 are 
blue in color while those of MEU 2 are pink in color. 
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